B&S: Command Line

[Czarak Ynehac]

Hi All,

My Bodgitt & Scarper assignment has the following instruction:


Target Platform and Execution
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>]

Your programs must not require use of command line arguments other than the single mode flag, which must be supported. Your programs must not require use of command line property specifications. All configuration must be done via a GUI, and must be persistent between runs of the program. Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory.

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.

You must not require manual editing of any files by the examiners.


I am confused by this instruction. To run the jar file I need to execute a command line as follows:

java -jar <path_and_filename> [<mode>]

Here <mode> can be one of the following three options:

1. server
2. alone
3. nothing

I believe I understand this part fine. However what should <path_and_filename> be? I'm guessing that should be the absolute path to where the application jar file is. If so this leaves me with some questions relating to the three flag options above:

In option 1 - if I am running the jar with the server flag, don't I need to tell the server what database file to use? Should it be possible for nothing to be specified here and a default database file to be used? Should all this be done via a gui after I run the command line with the server flag?

In option 2 - If I am running the jar with the alone flag, I need to give the standalone GUI a URL to tell it where the remote server is running - how should this be done? Also in a gui after the command line is executed? Am I correct in saying there should be no default option here - the user must specify the URL of the remote server?

In option 3 - If I am running the jar with no flag at startup, don't I need to tell the server what database file to use? Should it be possible for nothing to be specified here and a default database file to be used? Should all this be done via a gui after I run the command line with the server flag?

Am I leaving out any options which should be provided?

Any advice much appreciated!

Thanks in Advance.

[Andrew Monkhouse]

Hobo Soap,

Somehow I dont think that you are using your real name, or that Hobo Soap could be a real name. Could you please take a look at the JavaRanch Official policy on registered names and change your name to meet the requirements? You can change your name here.

Thanks, Andrew

[Czarak Ynehac]

Hi Andrew,

I have to admit I didn't read the naming policy when creating my account. My apologies and thanks for putting me straight!

[Andrew Monkhouse]

Hi Czarak,

Thanks for changing your displayed name.

Originally posted by Czarak Ynehac:
However what should <path_and_filename> be? I'm guessing that should be the absolute path to where the application jar file is.

I'd agree with that. It also fits well with the following:

From the instructions:
All configuration must be done via a GUI, and must be persistent between runs of the program. Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory.

Since the configuration options have to be stored in the current working directory it is probable (in my opinion) that your application will be started from more than one base directory, in which case the user would need to provide the absolute path to where the application jar file is.

Originally posted by Czarak Ynehac:
In option 1 - if I am running the jar with the server flag, don't I need to tell the server what database file to use? Should it be possible for nothing to be specified here and a default database file to be used? Should all this be done via a gui after I run the command line with the server flag?

See my earlier quote from the instructions .

Originally posted by Czarak Ynehac:
In option 2 - If I am running the jar with the alone flag, I need to give the standalone GUI a URL to tell it where the remote server is running - how should this be done? Also in a gui after the command line is executed? Am I correct in saying there should be no default option here - the user must specify the URL of the remote server?

Again, I think that the quote from the instructions covers most of this.

However you may still want to think about the default value for the first time the application is run from any given directory: do you provide no default or do you provide a loopback address as a default? For the test environment a loopback default might be reasonable. However in a real working environment I would probably choose between:

finding out from the customer a reasonable default is

allowing the customer to set a default in a standard location (say with the jar file) which could then be overruled by the option in the properties file

having no default

All could be correct for a given value of correct . Deciding what to do in your particular case, and then showing that you have thought about it (by documenting it in your choices document) is part of what makes you a developer.

Originally posted by Czarak Ynehac:In option 3 - If I am running the jar with no flag at startup, don't I need to tell the server what database file to use? Should it be possible for nothing to be specified here and a default database file to be used? Should all this be done via a gui after I run the command line with the server flag?

Again, I think that the quote from the instructions covers most of this.

Funnily enough I have just finished making comments to my technical reviewer regarding directories for a live deployment. In my assignment (Fly By Night Services) there were far fewer restrictions on what was not allowed, and there certainly wasn't the comment that you don't get extra marks for going beyond requirements. So many candidates doing that assignment went far beyond requirements - I suspect that this is why Sun have put certain words and restrictions into the current assignments . But in my assignment I allowed for 4 different directories: one for the database, one for the executable jars, one for documentation, and one for storing user preferences. I even documented why I considered having such a setup to be reasonable (I have had live deployments where such setups were mandatory). My application took reasonable attempts to determine what each directory would be, and did it's best to help future runs of the application find directories that were in "non standard" locations. It was fun, but I would definately recommend against doing that for the current assignments .

Regards, Andrew
[ September 09, 2005: Message edited by: Andrew Monkhouse ]

[Czarak Ynehac]

Hi again,

Thank you for your thoughtful reply Andrew. I believe I understand the direction you are trying to point me in to a certain degree.

This is my current understanding of the 3 options in running the jar with some questions still for anyone to comment on:

1. java -jar <\absolute\path\to\jar> server

Upon executing this command line, the user is presented with a small dialog box sized 'properties' gui. There are two scenarios:

A. This is the first time the server has been run from the current directory, i.e. no server properties exist in a properties file in the current directory. The 'properties' gui will prompt the user for the location of the database file. When a valid database file is specified by the user the location of this database file is recorded in the properties file for future runs of the server from the current directory.

B. This is not the first time the server has been run from the current directory, i.e. a properties file exists. If the properties file contains the location of a valid database file should I ask the user to confirm launch with this database file and provide the option of changing to another database file? Or should I launch the application with the database file specified in the properties file and bypass the properties gui altogether? Maybe both are valid - does anyone have an opinion on pros/cons for each approach?

Should I record the URL and Port number the server is running on in the propeties file in the current directory?

2. java -jar <\absolute\path\to\jar> alone

Upon executing this command line, the user is presented with a small dialog box sized 'properties' gui. There are two scenarios:

A. This is the first time the client has been run from the current directory, i.e. no client properties exist in a properties file in the current directory. The properties gui will prompt the user for the location of the server (i.e. URL and Port). When a valid server is specified by the user the location of this server is recorded in the properties file for future runs of the client program from the current directory.

C. This is not the first time the client has been run from the current directory, i.e. a properties file exists with a vaild server URL and Port. If the properties file contains the location of a valid server should I ask the user to confirm launch with this server and provide the option of changing to another server? Or should I launch the application with the database file specified in the properties file and bypass the properties gui altogether? Maybe both are valid - does anyone have an opinion on pros/cons for each approach?

If whenever a server is started from the current directory, the server records its url and port number in the properties file in the current directory, should this automatically be used when I try to start a client from the same current directory? What if more than one server has been started from the current directory?

3. java -jar <\absolute\path\to\jar>

Upon executing this command line, the user is presented with a small dialog box sized 'properties' gui. There are two scenarios:

A. This is the first time the server has been run from the current directory, i.e. no server properties exist in a properties file in the current directory. The 'properties' gui will prompt the user for the location of the database file. When a valid database file is specified by the user the location of this database file is recorded in the properties file for future runs of the server from the current directory.

B. This is not the first time the server has been run from the current directory, i.e. a properties file exists. If the properties file contains the location of a valid database file should I ask the user to confirm launch with this database file and provide the option of changing to another database file? Or should I launch the application with the database file specified in the properties file and bypass the properties gui altogether? Maybe both are valid - does anyone have an opinion on pros/cons for each approach?


Other Questions:
If someone tries to start a server with a specific database file and a server is already running in the JVM using that specific database file, is it valid for me to handle this by doing nothing except returning a message on the command line saying something along the lines of: "Server is already up with database file xyz.db" and returning the user to the command prompt?

Thanks in advance guys!

Czarak.

[Samuel Pessorrusso]

Other Questions:
If someone tries to start a server with a specific database file and a server is already running in the JVM using that specific database file, is it valid for me to handle this by doing nothing except returning a message on the command line saying something along the lines of: "Server is already up with database file xyz.db" and returning the user to the command prompt?

I think it is easier to document an assumption that more than one Server instance wont run with the same database file.

[Czarak Ynehac]

Hi Samuel,

Thanks for your reply. I am assuming no more than one server is going to run with the same database file in the same VM. My question on this issue was do people think this is an appropriate assumption, and given that assumption, how should I handle it when someone tries to do something other than what I am assuming is the allowed behaviour. i.e. what should happen when someone tries to execute a command line to run a server with a database file which is already being used by another server in the VM? As I suggested, should I give the user a message on the command line explaining there is another server running in this VM using that database file and return the user to the command prompt OR should I do something different?

Thanks,

Czarak.

[Andrew Monkhouse]

Hi Czarak,

It looks like most of your post was a copy and paste of two basic questions, 3 times:

If the properties file contains the location of a valid database file should I ask the user to confirm launch with this database file and provide the option of changing to another database file? Or should I launch the application with the database file specified in the properties file and bypass the properties gui altogether? Maybe both are valid - does anyone have an opinion on pros/cons for each approach?

Should I record the URL and Port number the server is running on in the propeties file in the current directory?

There are minor differences based on mode, but the basic questions are the same.

Regarding question 1, it needs somebody to start listing pros and cons of each approach, and then others can nitpick. That somebody could be you!

I think the major positive of getting confirmation of the options is that if the user wants to change something (say the port number) they can do it easily at startup time from within the GUI. The negative is that they have to press the "OK" button (or "connect" or whatever you call it) - but that is such a minor negative that I don't consider it a real negative.

The alternative is that if (for example) the user wanted to change the port number they would have to either edit the properties file (not allowed) or they would have to delete the properties file and re-enter all the options. This to me is a much greater negative, and more than offsets the minor positive of not having to click "OK".

Regarding question 2: Do your instructions specify "All configuration must be done via a GUI, and must be persistent between runs of the program." (my highlighting)? If so, does that answer your question?

If someone tries to start a server with a specific database file and a server is already running in the JVM using that specific database file, is it valid for me to handle this by doing nothing except returning a message on the command line saying something along the lines of: "Server is already up with database file xyz.db" and returning the user to the command prompt?

If you are trying to start two servers in the same JVM, then this could only happen if you explicitly coded your server in such a way that this was possible. Otherwise any other server would start in it's own JVM. So simple answer: don't write your server such that running the one command "java -jar runme.jar server" can result in two servers running.

If you are worried about somebody running the command "java -jar runme.jar server" twice simultaneously (or running any other sequence of commands that would result in two applications accessing the database simultaneously), then you don't have to worry about it. The instructions explicitly state that: "You may assume that at any moment, at most one program is accessing the database file".

Regards, Andrew