Forums Register Login

NX Contractor - startup mode

+Pie Number of slices to send: Send
I know this has been discussed before, but I am still a bit confused...
The specs say "The mode flag must be either "server", indicating the server program must run, "alone", indicating standalone mode, or left out entirely, in which case the network client and gui must run."
I interpret this as:
"server" argument - just start the RMI server, no client GUI presents itself?
"alone" argument - start GUI in local(standalone?) mode, no choice to pick local or network database
no argument - GUI starts in network mode, again no choice to pick one or the other?
From the wording it almost seems there is no option for an end user to select standalone or network mode via the GUI... and the line in the specs regarding "All configuration must be done via a GUI, and must be persistent between runs of the program" seems to indicate that the "configuration" would be perhaps the location of the database (if they selected standalone) or the server and port if they selected "server".
I would of thought that you would also store the user preference of "standalone", "server" or "no argument" as well, but it appears you make that choice from the command line, and it's a "done deal" by the time you hit any kind of GUI.
+Pie Number of slices to send: Send
Yeah, a "real world" application might well set things up differently. E.g. I would want the option to specify server properties without requiring any GUI, e.g. using a -f [propfilename] option to tell it to just use those properties and don't ask any questions dammit. This would make it easier to run the server from a script, for example. But we're not in the real world, we're just implementing Sun's spec, silly or no. Your understanding of the requirements appears correct.
+Pie Number of slices to send: Send
Thanks, Jim! In a somewhat related question, regarding some of what I said above...

"All configuration must be done via a GUI, and must be persistent between runs of the program" seems to indicate that the "configuration" would be perhaps the location of the database (if they selected standalone) or the server and port if they selected "server". I would of thought that you would also store the user preference of "standalone", "server" or "no argument" as well, but it appears you make that choice from the command line, and it's a "done deal" by the time you hit any kind of GUI.


This appears to suggest no storing of "network vs. local" preferences, as these will always be decided from the command line (entering a mode or leaving blank).
For "alone" mode, the only property to store in suncertify.properties would be the location of the local database, I guess. It seems logical that the database shored be stored in the User's working directory, along with their suncertify.properties. However Sun says to provide them with a copy of the original *.db file they sent me. So I am assuming that there will actually be two *.db files, One pristine copy in the location Sun specifies in the hierarchy, and another "working" copy of the *.db, perhaps located in the user's working directory...
+Pie Number of slices to send: Send
I've interpretted that requirement differently. I assumed it only applied to the Client program, not the server program. My server program takes no arguments and just rund. Eg. java Server. My client however runs in either local or server mode. And the flags are server, alone or nothing, where nothing = server.
I dont know which interpretation is correct, but it just doesnt seem right to start the client and server from the same command.
+Pie Number of slices to send: Send
This appears to suggest no storing of "network vs. local" preferences, as these will always be decided from the command line (entering a mode or leaving blank).
Agreed.
For "alone" mode, the only property to store in suncertify.properties would be the location of the local database, I guess. It seems logical that the database shored be stored in the User's working directory, along with their suncertify.properties. However Sun says to provide them with a copy of the original *.db file they sent me. So I am assuming that there will actually be two *.db files, One pristine copy in the location Sun specifies in the hierarchy, and another "working" copy of the *.db, perhaps located in the user's working directory...
Yes. Well, I don't care if they leave the one copy pristine or not; that's up to them. If they screw it up they can should still have my original jar file; they can recover it if necessary. I figure the tester can use any working directory he wants. That dir may or may not have a suncertify.properties file in it to begin with; if there is a props file and it contains a DB location, that will appear as the default DB file to be used unless the user chooses to override the default with GUI configuration. Or if there was no props file (or no DB location in the props file) user will basically have to specify one with GUI configuration on startup. Once the user has specified a DB file, that will be stored in the props file for any future program runs from that director. One way or another though - the user can ultimately specify any DB file they want; it's up to the user to decide if they want to edit the "pristine" version, or make a copy elsewhere. That's beyond our control, I think.
+Pie Number of slices to send: Send
My server program takes no arguments and just rund.
What DB file does it access? Does it assume that the current working directory will have a file named [whatever your file is called], or is there some way to configure this?
My client however runs in either local or server mode.
Not sure what this means - seems very strange to me though. How does a client run in server mode? Aren't those opposites?
+Pie Number of slices to send: Send
What DB file does it access? Does it assume that the current working directory will have a file named [whatever your file is called], or is there some way to configure this?
This can be configured via the suncertify.properties file which is modifyed in the GUI. and I also have a way of detecting a non existing or currupt db file when the server starts up and then I prompt the user for the db location.
Not sure what this means - seems very strange to me though. How does a client run in server mode? Aren't those opposites?
When the client is in server mode it tries to connect to a Server (via RMI) in alone mode it simply looks for a database file, again this file is specified in the suncertify.properties.
The point of my original message was simply that I have 2 commands to start my respective applications, one for the server and one for the client (the GUI application). Which is what I interpretted from the requirements, which differs from BillLeightons interpretation and I'm not sure who is correct.
+Pie Number of slices to send: Send
Sorry Guido; I read too quickly, and thought your server didn't provide any GUI config option either. That's what motivated some of my questions - never mind now; I see I misread. However, I disagree with you (and agree with Bill) regarding your interpretation:
I've interpretted that requirement differently. I assumed it only applied to the Client program, not the server program. My server program takes no arguments and just rund. Eg. java Server. My client however runs in either local or server mode. And the flags are server, alone or nothing, where nothing = server.
Here are the relevant requirements from my assignment (unless yours is different):

When you submit your assignment, each part (client and server) must be executable using a command of this exact form:
java -jar <path_and_filename> [<mode>]
...
The mode flag must be either "server", indicating the server program must run, "alone", indicating standalone mode, or left out entirely, in which case the network client and gui must run.


The last sentence makes it sound like "server" and [nothing] are two different things. I think that "server" means "run the server" rather than "run a client that expects a server". And [nothing] means network client and gui, which I believe is what you call a client in server mode - that is, a client that expects to connect to a server, rather than standalone. There are really only three things you might need a program to do:
1. Start a server
2. Start a client which expects a server.
3. Start a client with local DB.
These 3 options seem to map directly to the modes
1. server
2. [none]
3. alone
So all three modes can be run from the same executable jar file. Each mode means something different; no need for any duplication (like your [nothing] = server).
I agree that the specs aren't entirely clear on this point - but I don't see any reason to separate the main client program from the main server program, and it seems to create additional confusion, with two modes that do the same thing, and "client in server mode" requires extra explanation for some people (like me).
Oh, wait - just saw another bit of evidence. The "Packaging of Submissions" section of the instructions refers to "The executable JAR containing the programs. This must be called runme.jar." Sounds like there's just one executable jar file. So if you start programs with
java -jar <path_and_filename> [<mode>]
as specified, the <path_and_filename> will always have to point to that jar file. How could you have one for client and one for server? Doesn't seem possible in the instructions. I think this confirms that all client and server code is in one program, and you choose which to run based solely on the mode.
Are you here to take over the surface world? Because this tiny ad will stop you!
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 918 times.
Similar Threads
Database location
Running server/client separately in runme.jar
Help needed with confusing requirements...
NX: Spec Confusion
How many modes are there for the program?
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 23:29:09.