Don't understand mode flag

[joel smither]

Need some clarification with respect to the use of the mode flag on the UrlyBird project....

The project requirements state that when we submit the assignment, each part (client and server) must be executable using a command of the following form:
java -jar <path_and_filename> [<mode>]

The client and server prorams accept at most only a single command line argument, a "mode flag".

If the mode flag passed in is "server", just the server runs
If the mode flag is "alone", the client runs in standalone mode (i.e. it connects to a local database, no server needed)
If the mode flag is left out entirely, the client and server must run in networked mode.

Additionally, the requirements state that all configuration must be done via a GUI and must be persistent between runs of the program. The configuration information must be stored in a file called xxx.properties

I have the following questions....
(1) To run in standalone mode (i.e. client passed a mode flag of "alone", does the client gui need to provide the user with the ability to specify the location of the local database file? A JTextField perhaps?

(2) If the mode flag is "server", the server program needs to be brought up. Does it need to provide a gui to the end user to allow the user to specify host, port and database file information for a remote connection? I'm assumming the only time you bring up the server program is when you want to connect remotely to the database. I'm using RMI.

(3) If the mode flag is left out entirely, what does this really mean? Do I just start up the client (assumming I've already started the server by passing in a mode flag of "server") to connect remotely to a database file. As a result, will the client gui need to allow the user to specifiy the host and port for the remote connection (no need to to have the client specify the location of the database file, we are going to connect to it remotely, the server will specify the name and location of the database file)?

(4) Does the xxx.properties file store configuration for BOTH the client and server? I'm not sure how this mechanism should work.

Any help would be deeply appreciated.

[peter wooster]

Originally posted by joel smither:
Need some clarification with respect to the use of the mode flag on the UrlyBird project...

The mode flag controls the startup mode of the program.

alone = run as a monolithic program using local files. This mode is handy for configuring the file to use since it gives immediate feedback on whether the file is valid.

server = run as a server, you may include a GUI if you wish, I do and let the user configure network parameters. Note that once RMI is running, you can't switch ports without shutting down if your server contains the registry. I inform the user and then let them continue to use the old settings if they wish.

(omitted) = run as a networked client. This mode should be able to chose a server, you may actually want to test with several servers on the same machine and by reconfiguring the server and restarting it. You definitely want to test with multiple clients and multiple machines.

I provide GUIs for all modes, with them sharing the same properties file. I also provide default values to use if the properties are not available.

[Eric Chang]

I pretty much do the same as what Peter did. I provide popups for all modes to configure the properties, and one the client or server is started successfully, I save the settings to the .properties file, which is used to provide the default settings the next time the user starts the client or server. So the following flags will allow the user to configure the following settings:
server = configure the port and location of the database file
alone = configure the location of the database file
(none) = configure the ip and port of the server

I also provide a GUI for the server, as I'm not sure how one would go about doing the configuration of the server without adding additional cmd-line arguments to the server, which is prohibited. I guess you could just go for prompting the user for them in the console with System.out and reading in the input, but I figured a GUI is a lot more user-friendly, and is fairly simple considering the amount of GUI coding you're sure to have already done for the client.

[joel smither]

thanks for the reply....

Let me sum up what I think you are trying to tell me...

To run standalone, my client needs to connect to a local database file. Doesn't this imply the client should have a gui that allows the user to specify the name and location of this file?

In terms of the server, it should have a gui that allows the user to specify the name and location of the database file, as well as the host and port right? How do you not allow the the user from switching port, host, database file information once RMI is up and running? Do you just popup a dialog that tells them they need to shut things down and restart?

If I omit the mode flag, we want a networked connection between client and server. Doesn't the client gui need to get host and port information from the user in this siutation just like the server gui?

I'm not sure what the client gui should provide and what the server gui should provide. Could you itemize a list for me so it is more clear? In other words the client should maintain database file and location info, host info, port info...the server should provide ....

Also, could you elaborate a bit more about the properties file? The client and server don't need to be started in the same directory do they? As a result, where does the one properties file reside? When does it get read/written? It seems to me all it needs is the name and location of the database file, host and port.

Any help would be deeply appreciated.
Thanks in advance!

[Eric Chang]

This is what I did:

alone flag
I provided the user with a dialog to input the location of the local database file. If a properties file already exists, then I would read in the database file location from it, and if not, I would use a default one. Upon the successful start of the client, the database location would be saved in the created properties file (or if it already existed, would modify the database location in the properties file).

server flag
I had a server GUI to allow the user to configure the port and location of the database file. I did not allow for the user to configure the IP because I assume it will be running on the local machine (ie: localhost).
If the user wants to pick another port or database file location, they would have to restart the server. You'll find there is already a discussion about shutting down the RMI Server in a previous thread somewhere.

no flag
This will only bring up the client, where the user is prompted to enter the server IP and port.

For all of them, I either create the properties file if it doesn't exist, or modify the contents of it if it does exist. I hold the host, port, and datafile location in the properties file.

Now, you might find that you want to do it a different way, which would be fine, just make sure you don't require the user to modify the properties file directly, but rather through the server or client GUIs. And I'm sure there are other people here who did something different...it all depends on what you think is the best approach. The only thing is that the properties file could be the same file for the client and server if both are running on the same machine and directory, so you might to watch out for that.

[peter wooster]

Originally posted by joel smither:
thanks for the reply....

Let me sum up what I think you are trying to tell me...

To run standalone, my client needs to connect to a local database file. Doesn't this imply the client should have a gui that allows the user to specify the name and location of this file?

The easiest route is to provide configuration options in all modes using a GUI. These can probably share quite a bit of code.

In terms of the server, it should have a gui that allows the user to specify the name and location of the database file, as well as the host and port right? How do you not allow the the user from switching port, host, database file information once RMI is up and running? Do you just popup a dialog that tells them they need to shut things down and restart?

Once the RMI registry is running you can't shut it down or restart it without shutting down the program its part of. I use createRegistry, so I am required to shut the server to activate a new config. Also if you change the database file there is a whole mess of problems related to active clients, so you might want to shut down in that case as well. What I do is give the user the option to either shut down or continue as is. I do open the new file. I also display the current active file and port in the server GUI, and the configured port if it differs from the active one.

If I omit the mode flag, we want a networked connection between client and server. Doesn't the client gui need to get host and port information from the user in this siutation just like the server gui?

The client will get a default port of 1099 and address of localhost if its not configured. The user should be able to set these to appropriate values.

I'm not sure what the client gui should provide and what the server gui should provide. Could you itemize a list for me so it is more clear? In other words the client should maintain database file and location info, host info, port info...the server should provide ....

network client: server port, server address
standalone client: database file
server: database file, server port

Also, could you elaborate a bit more about the properties file? The client and server don't need to be started in the same directory do they? As a result, where does the one properties file reside? When does it get read/written? It seems to me all it needs is the name and location of the database file, host and port.

The properties file is in the current directory according to my instructions, thus its quite possible to have different properties in several directories. This allows you to run several servers on the same host by starting them from different directories.

Any help would be deeply appreciated.
Thanks in advance!

You're welcome.

[Davinder Kohli]

I have the B&S assignment, I have the same requirement. My thinking is the along the same lines as what you all are proposing or going with. I am using sockets instead of RMI.

Here are my thoughts, please comment...

In my GUI, I provide the Connect menu for the user to provide the db information. In this dialog box, the user may select either Local or Remote.
Local meaning the db is located on the same machine as the GUI, thus requiring no network configuration (thus no server). All the user has to provide is the db location.
Remote means the db server may be located on the same or different machine and requires a network connection. The user has to thus provide IP, port, and db location.
In both the cases, the properties file gets the information the first time and then onwards retains this info.

runme.jar -alone
[There is no server in this case]
The client GUI is brought up and the user must provide the db information, in the connect box which is defaulted to Local.

runme.jar <no flag>
[The server is either on the same machine as the client or on a different box]
The client GUI is brought up and user must provide the ip, port and db location, in the connect box which is defaulted to Remote.
In this case if the db is valid, the client first tries to connect to the Server at the given ip and port and if cannot, then launches the server locally on the client machine. It tests the connection to verify if the db is a valid one.

runme.jar -server
[The server is either on the same or different machine than the client]
A GUI( for the server only) is brought up the first time to get the port and ip and db info and runs the server only. The next time around this information is saved in the properties file, so the GUI is brought up with the information filled up for the user to verify/change.

Now if the user needs to launch the GUI, it needs to run runme.jar without any flag. The user uses the "Connect" menu to provide the db connection information, and can test this connection from the GUI.


Open to suggestions, I have not begun implementing this yet, but I am thinking of going with this.

[peter wooster]

Originally posted by Davinder Kohli:
I have the B&S assignment, I have the same requirement. My thinking is the along the same lines as what you all are proposing or going with. I am using sockets instead of RMI.

Here are my thoughts, please comment...

In my GUI, I provide the Connect menu for the user to provide the db information. In this dialog box, the user may select either Local or Remote.
Local meaning the db is located on the same machine as the GUI, thus requiring no network configuration (thus no server). All the user has to provide is the db location.
Remote means the db server may be located on the same or different machine and requires a network connection. The user has to thus provide IP, port, and db location.
In both the cases, the properties file gets the information the first time and then onwards retains this info.

runme.jar -alone
[There is no server in this case]
The client GUI is brought up and the user must provide the db information, in the connect box which is defaulted to Local.

runme.jar <no flag>
[The server is either on the same machine as the client or on a different box]
The client GUI is brought up and user must provide the ip, port and db location, in the connect box which is defaulted to Remote.
In this case if the db is valid, the client first tries to connect to the Server at the given ip and port and if cannot, then launches the server locally on the client machine. It tests the connection to verify if the db is a valid one.

runme.jar -server
[The server is either on the same or different machine than the client]
A GUI( for the server only) is brought up the first time to get the port and ip and db info and runs the server only. The next time around this information is saved in the properties file, so the GUI is brought up with the information filled up for the user to verify/change.

Now if the user needs to launch the GUI, it needs to run runme.jar without any flag. The user uses the "Connect" menu to provide the db connection information, and can test this connection from the GUI.


Open to suggestions, I have not begun implementing this yet, but I am thinking of going with this.

You're making it overly complicated. Its easier to have each mode provide a GUI that sets its options. You should not allow the user to change modes dynamically. the instructions are quite explicit about the modes. In particular the "alone" mode must not use any networking.

[joel smither]

I want to thank EVERYONE for the outstanding information.

I do have one additional question though.
I have a seperate program for my client, a seperate program for my server. I'm supposed to jar all my software up so I can run the client or server according the following command line: java -jar <path_and_filename> {<mode>]

I'm assumming the "path_and_filename" listed above refers to the name of the jar file. I think I'll need to build a manifest file so that when I run the jar file the java interpreter will know which main function to run.

My question is this: is it in that main function where I look at the mode flag and either launch a client process or server program?

[Eric Chang]

I am guessing that you are supposed to have one and only one class with a main method that runs either the client or the server.

[Jim Janssens]

So, I'll write up a short resum� since its also interests me. Correct me if I'm saying things that are inconsistent with the things said.

java -jar <file&path> alone

-> launches the client gui. When the client's configuration panel is loaded, it will only show the components for selecting the database file. There are nowhere settings for server ip or port.

java -jar <file&path> server

-> launches the server (or server gui if you have one)

java -jar <filep&path>

-> launches the client in server mode. Meaning that when the configuration dialog is opened, there are settings for the server ip and port (the database file selection stuff is not visible in this mode)

So if sun wants to test the application in network mode they have to first start a vm with "java -jar <file&path> server" , next another one with "java -jar <file&path>"

If they want to start the client connecting to a local database file, they would start it with "java -jar <file&path> alone"

I supose there are 3 main classes

- A main for starting the server
- A main For starting the client (accepts one command line parameter)
- A main method which is also put in the manifest. This main method is executed every time one of three modes is requested. This main will start one of the two other mains. This when the argument is "server" he starts the main from the server. when the argument is "alone" he starts the main from the client and passes "alone" so the client knows it should hide the "server settings" from the configuration panel and show the database file configuration. When no parameter is passed, the main of the client knows it has to show the server configuration and hide the database file configuration.

[Eric Chang]

That looks right to me, but I only have one main method, which instantiates either the Client or the Server depending on the mode flag put in the arguments. But whatever works in the end.

[Paula Decker]

Hi Peter,

I also have B&S. One of your emails read:

runme.jar -alone
[There is no server in this case]
The client GUI is brought up and the user must provide the db information, in the connect box which is defaulted to Local.

runme.jar <no flag>
[The server is either on the same machine as the client or on a different box]
The client GUI is brought up and user must provide the ip, port and db location, in the connect box which is defaulted to Remote.
In this case if the db is valid, the client first tries to connect to the Server at the given ip and port and if cannot, then launches the server locally on the client machine. It tests the connection to verify if the db is a valid one.

runme.jar -server
[The server is either on the same or different machine than the client]
A GUI( for the server only) is brought up the first time to get the port and ip and db info and runs the server only. The next time around this information is saved in the properties file, so the GUI is brought up with the information filled up for the user to verify/change.

According to the Packaging of Submissions section, the database file must be located in the root directory and have the same name as the original file. Given this, I don't see why the user has to enter any db location or information.

Thanks, and I appreciate this thread.

-Paula

[Bridget Kennedy]

Originally posted by Paula Decker:
Hi Peter,

I also have B&S. One of your emails read:

According to the Packaging of Submissions section, the database file must be located in the root directory and have the same name as the original file. Given this, I don't see why the user has to enter any db location or information.

Thanks, and I appreciate this thread.

-Paula

What you say is true, but there is also a line in the "Network Approaches" section that says "In either case, the program must allow the user to specify the location of the database...".
[ January 05, 2005: Message edited by: Bridget Kennedy ]

[Paula Decker]

Thanks, Bridget...I missed that.

-Paula

[Frans Janssen]

Originally posted by Bridget Kennedy:


What you say is true, but there is also a line in the "Network Approaches" section that says "In either case, the program must allow the user to specify the location of the database...".

[ January 05, 2005: Message edited by: Bridget Kennedy ]

Bridget,

I am not sure that "the location" refers to the location on the file system. The line you quote is a bit longer in fact:

In either case, the program must allow the user to specify the location of the database, and it must also accept an indication that a local database is to be used, in which case, the networking must be bypassed entirely.

In this context, "the location" might very well be interpreted as the IP address of the server, because it is presented as opposed to a local file.

But anyway, I am not taking chances and have added a file selection dialog in the server's UI, just in case

Frans.

[Charles Fung]

I do not quite agree. If you read carefully, the requirement is under Network Approaches. 'In either case...' refers to the RMI and serialized objects over socket approaches.
'must allow the user to specify the location of the database, ' means that the client program should be able to specify the location of the server program, i.e. the computer that the server program is running.
In practice, the server must be running before the client starts. When the client starts, you need to tell it where to connect to. The requirement is to prevent hardcoding the server machine.
Also, it is not practical for the client program to specify the location of the database file on the server machine. If you allow the client to specify where to get the database file, different clients may be reading from different files, and that is bad.

[Bridget Kennedy]

Originally posted by Charles Fung:
I do not quite agree. If you read carefully, the requirement is under Network Approaches. 'In either case...' refers to the RMI and serialized objects over socket approaches.
'must allow the user to specify the location of the database, ' means that the client program should be able to specify the location of the server program, i.e. the computer that the server program is running.
In practice, the server must be running before the client starts. When the client starts, you need to tell it where to connect to. The requirement is to prevent hardcoding the server machine.
Also, it is not practical for the client program to specify the location of the database file on the server machine. If you allow the client to specify where to get the database file, different clients may be reading from different files, and that is bad.

Agree. I would not advocate allowing the clients to specify data file location. In the case of the database location requirement, I assume 'user' refers to be the person who is invoking the server, not the client. My client only has the means to specify machine name/IP and port for the server.