NX:Some Questions(URLyBird1.3.2)

[xi ruo]

This is a section of my assignment:

Network Approaches
Your choice of RMI or serialized objects will not affect your grade, but no other approach is acceptable. 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. No authentication is required for database access.

the program must allow the user to specify the location of the database
Q:How to specify the location of the database?
a local database is to be used, in which case, the networking must be bypassed entirely.
Q:How to understand this section saying?

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.

Q:What's the single mode flag?
Q:What's the suncertify.properties file?
What's the format for this file?
How to use???

thanks for your help!!!

[Philippe Maquet]

Hi Xi,
Sorry for being very short in my reply, but I've not much time tonight.

the program must allow the user to specify the location of the database
Q:How to specify the location of the database?

See JFileChooser.

a local database is to be used, in which case, the networking must be bypassed entirely.
Q:How to understand this section saying?

Your client in stand-alone mode "talks" to the database directly or through some adapter/fa�ade class which is not, in any way, network-related (no RMI neither sockets).

Q:What's the single mode flag?

In my instructions, it's either server, alone or nothing :

java - jar runme server      = server is started
java - jar runme alone       = client is started in standalone mode
java - jar runme             = client is started to be connected to a running server

Q:What's the suncertify.properties file?
What's the format for this file?
How to use???

See class java.util.Properties.
Best,
Phil.
[ September 14, 2003: Message edited by: Philippe Maquet ]

[xi ruo]

Hi Philippe,thanks for your response.
I am still little understand.
When do I specify the location of the database after running?
What message is stored in the file called suncertify.properties ???

[Philippe Maquet]

Hi xi,

When do I specify the location of the database after running?

At least the first time your server is run (because before opening the database you obviously need to know where is is ). You save that location in suncertify.properties for later reuse with a key like "dbLocation" for example, in such a way that the next time your server is started, that location can be retrieved from suncertify.properties without user input and the database opened immediately. The user should also be able to alter that location when he decides it (by a click on some JButton or by selecting a menu item).

I don't understand the question

All properties are saved by use of an instance of the Properties class (see this class in your java doc). Properties you save have the form key / value (example : "dbLocation" / "c:/scjd/data").
Regards,
Phil.

[xi ruo]

Server end,must to specify the location of the database in the file which is "DatabaseImpl.java"??
In the DatabaseImpl file,must the update and delete methods locking?

[Tony Collins]

No.
Your Server should really have a GUI, when started it should check for a properties file, to gain the location of the database file and the port number to start the rmi server on. If these are not available the gui should allow the user to configure these properties. Thus allowing the server to start( I personally enable a start server button on the gui when I have these values). You should then start the database with the path of the database and create the connection handler on the required rmi port.
The configuration properties should then be saved when the server is shut down.
An instance of DatabaseImpl would be better wrapping an instance of your database accesss class.
Tony
[ September 15, 2003: Message edited by: Tony Collins ]

[Max Habibi]

I disagree. There's no requirement based reason for your server to have a GUI.
M

[Tony Collins]

Maybe, but this is the requirement that lead me to a GUI on the server.

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 client can't configure the server so I think a GUI is required, in my instructions anyway.
Tony

[Max Habibi]

Hi Tony,
By and large, they're talking about the client configuration here. Which server, which port, etc. In terms of the server, the only things you need to pass in are legal command line arguments, like port, mode, db location, etc.
M

[Jim Yingst]

By and large, they're talking about the client configuration here. Which server, which port, etc. In terms of the server, the only things you need to pass in are legal command line arguments, like port, mode, db location, etc.
I think there are different versions of the requirements floating about here. Dunno about Tony, but my assignment includes the same line quited by xi ruo above: "Your programs must not require use of command line arguments other than the single mode flag, which must be supported." We can't pass port or DB location to the server. We can read this from the properties file, but since we also need to be able to edit the properties with a GUI, and we can't specify whether or not the GUI properties editor is started up as part of the server (vs. simply starting the server with no GUI at all, the way we'd probably prefer) it seems that our only choice is to always start up some sort of GUI whenever the server is started, which at least offers the option of editing the properties before continuing. So maybe the "GUI" for the server is just a short popup that you dispose of before the server really starts. But it seems like there has to be some sort of minimal GUI here, for me an xi ruo at least, and probably Tony, and anyone else with the same mix of requirements1. Kinda sucks because this makes it hard to start up the server with a simple startup script or cron job the ways many sysadmins would prefer, but that's what [our version of] Bodgett & Scarper seem to have stuck us with...
Tony's server GUI sounds a little more involved than mine. Mine just says "here are the server config values" and you either edit them or don't, then press OK. Then the new values are saved and the rest of the server starts up. The only other thing needed is an exit - I just let the user hit ^C or whatever. Tony's version could be a little more elegant in this regard, since there's still a window up while the server is running.
[ September 15, 2003: Message edited by: Jim Yingst ]

[Vlad Rabkin]

Hi,

We can't pass port or DB location to the server. We can read this from the properties file, but since we also need to be able to edit the properties with a GUI...

The only opportunity to avoid it is to hard-code port and db location, which is to my oponion inacceptable. The only thing we can do easear is to stop server with Ctrg-C.
I've done a window to stop the server, but I will probably through it away.

Best,
Vlad

[Max Habibi]

Originally posted by Jim Yingst:
By and large, they're talking about the client configuration here. Which server, which port, etc. In terms of the server, the only things you need to pass in are legal command line arguments, like port, mode, db location, etc.
I think there are different versions of the requirements floating about here. Dunno about Tony, but my assignment includes the same line quited by xi ruo above: "Your programs must not require use of command line arguments other than the single mode flag, which must be supported." We can't pass port or DB location to the server. We can read this from the properties file, but since we also need to be able to edit the properties with a GUI, and we can't specify whether or not the GUI properties editor is started up as part of the server (vs. simply starting the server with no GUI at all, the way we'd probably prefer) it seems that our only choice is to always start up some sort of GUI whenever the server is started, which at least offers the option of editing the properties before continuing. So maybe the "GUI" for the server is just a short popup that you dispose of before the server really starts. But it seems like there has to be some sort of minimal GUI here, for me an xi ruo at least, and probably Tony, and anyone else with the same mix of requirements1. Kinda sucks because this makes it hard to start up the server with a simple startup script or cron job the ways many sysadmins would prefer, but that's what [our version of] Bodgett & Scarper seem to have stuck us with...
Tony's server GUI sounds a little more involved than mine. Mine just says "here are the server config values" and you either edit them or don't, then press OK. Then the new values are saved and the rest of the server starts up. The only other thing needed is an exit - I just let the user hit ^C or whatever. Tony's version could be a little more elegant in this regard, since there's still a window up while the server is running.
[ September 15, 2003: Message edited by: Jim Yingst ]

Thanks Jim,
I stand corrected
M

[Philippe Maquet]

Hi everyone,
Jim is right, in some instructions a server GUI is mandatory (the case in URLyBird 1.2.1).
But why just "a short popup that you dispose of before the server really starts" like Jim maybe sugests ? That solution implies that any administration task executed server-side force all clients to be and stay disconnected while the task is performed. It is more user-friendly to have a permanent server GUI, which offer additional benefits : recall of the main network settings (server IP address and listen port), direct access to network and database settings, and even maybe an embryo of monitoring (network and database).
Best,
Phil.
[ October 24, 2003: Message edited by: Philippe Maquet ]

[Jim Yingst]

But why just "a short popup that you dispose of before the server really starts" like Jim maybe sugests ?
Ummm... Keep It Simple? Yes, I do sometimes follow this advice. Basically I was getting tired of playing with layout managers for more complex screens (GUIs aren't really my thing) so I went with the simplest design I could think of for this part. And aside from the extra effort for the GUI design - how do you do something like let the user change, say, the port number, without stopping and restarting the server? I suppose it can be done other ways, but my solution is: for the user to stop the server on the current port #, then restart the server, and specify a different port. Is there a simpler way to do this? More generally, none of the additional features you suggest seemed necessary, though they do seem like they might be nice, if someone wants to take the time to put them in. Perhaps I am overlooking a simple way to implement this. I hadn't really thought about it.

[xi ruo]

thanks for all replyer:
Now I decide to use a GUI for server-side,following:
One JFrame - title is "serverFrame",include three JButton;
|-- setting JButton - open a JDialog which called "serverSetting" to set
|-- startup JButton - startup the rmi server
|-- shutdown JButton - shutdown the rmi server and close serverFrame and exit System
one JDialog - title is "servetSetting",include:
|-- JLabel - text is "Data file location"
|-- JLabel - text is "Server port"
|-- JTextField - name is "dataFileLocation"
|-- JTextField - name is "serverPort"
|-- JButton - name is "selectButton",open a JFileChooser dialog to select the data file location
|-- JButton - name is "okButton",save the dataFileLocation and the serverPort to a file which called "suncertify.properties" and close the settingDialog
|-- JButton - name is "cancelButton",cancel all operation in the settingDialog and close the settingDialog
Please comment.

[Tony Collins]

Xi why don't you have your Configuration in a drop down menu.
Additionally I think using CTRL-C for stoping the server is bad, as it's effectivelly a user controlled crash so you lose control of actions that should be carried out when you close down the server, i.e saving the properties file.
Does anyone have the opinion that there is more work in the new assignements than the old ones.
Tony

[Tony Collins]

I allow the user to change the settings for the server to start up on, not actually re-start the server. So you need to change properties exit and re-start my GUI from the command line.
Re-starting the server from the GUI seemed a pain to me as the client may still have references to a un gc'ed remote object, if the server isn't completelly exited. I supose I could put a simple check in but thats more complexity that isn't specifically required.
Tony

[Philippe Maquet]

Hi Jim,

Ummm... Keep It Simple? Yes, I do sometimes follow this advice. Basically I was getting tired of playing with layout managers for more complex screens (GUIs aren't really my thing) so I went with the simplest design I could think of for this part.

I understand that so much ! When I finished the db part, I promised to myself to keep everything as simple as possible in the next two parts. Well, my network solution is all but simple, but I then promised to be at least faithful to the first one for the GUI part, and ... I see now that I get trapped by myself :
Would it make sense to present a db design (and defend it) with features like a fine-tunable caching system and optional field indexes if the grader cannot play with them, worst cannot check that your system still works when those features are used (indexes example : findByCriteria() with no indexes (sequential search), with one of both fields indexed (indexed search), with only one of them indexed (mixed search)). IMO, supporting multiple configuration options forces you to offer a way for the grader to test them. In the network area (sockets), I have similar properties which may be set (port and server IP address, but also buffer sizes and timeouts).

And aside from the extra effort for the GUI design - how do you do something like let the user change, say, the port number, without stopping and restarting the server?

I would add "and without stopping and restarting the clients ?".
I never finished with the description of my network sockets implementation started in
this thread (because I felt like a bit discussing for/with myself ).
Here is how it will work (I am just working now on the server GUI part) :
Let's say that you change the port (and/or the IP Address - presented in a comboBox in the case your server machine owns multiple addresses) and save the new configuration. You are there in the sub-tab "Network" of the tab "Settings" of my main JTabbedPane. Nothing happens except a save in suncertify.properties.
Now let's say that you go to the main tab "Actions" and, in the group box "Network" you click on the "Restart" button. Connected clients stay connected on their existing permanent connection, the "main door" is closed (the thread where ServerSocket.accept() accepts new connections), and reopened with the new settings.
If, instead of clicking the "Restart" button, you click the "Shut Down" one, followed by a click on "Start", existing client connections will be disconnected (after their current operation is finished if any), and clients will popup their Connect dialog. Quite normal. What is more interesting is that their "default" connect settings will appear to the user updated. I like it because it's user-friendly (no need for phone calls or mails to tell users that the port has changed) and it looks a bit like magic .
Nothing complex in the code anyway : as I support callbacks already to implement broadcasting server messages to clients, I just need to implement a Command called ConnectionSettingsChanged for example and broadcast it to clients just before shutting down (BTW, I'll do the same after the "Restart" described above). Client-side, that command does nothing else than update its default connection settings. 4-5 lines of code both sides for a quite funny effect ! You'll probably agree with me that it's quite compelling to achieve...
Trapped by my own trap !
Best,
Phil.

[Vlad Rabkin]

Hi,
Phil:

I promised to myself to keep everything as simple as possible ...

Do you beileve yourself?
Best,
Vlad

[Andrew Monkhouse]

Hi Tony,

Additionally I think using CTRL-C for stoping the server is bad, as it's effectivelly a user controlled crash so you lose control of actions that should be carried out when you close down the server, i.e saving the properties file.

You might be interested in looking at the addShutdownHook() method of Runtime. It removes the concern you listed above.
Jim made a comment about being able to automate startups. Trapping Ctrl-C does not help with startups, but it does help with shutdowns. You can now automate a clean shutdown if necessary (say power went off).

Does anyone have the opinion that there is more work in the new assignements than the old ones.

Nah, when I was a young lad, we had it much harder than you young 'uns. You don't know what hard is.
Seriously, we had our own issues to contend with, such as we had to be able to call lock from the client code, but could not use cookies and we really needed to have only one instance of the Data class. Most of the current assignments either use cookies or you can have multiple instances of Data class (or people avoid the whole issue by only calling the lock method on the server side).
Regards, Andrew

[Tony Collins]

Cheers Andrew have you a fair amount of experience using Java you seem to have a good graso of the API's.
Tony

[Andrew Monkhouse]

Hi Tony,
Thanks. I have a few years experience with Java, but I am still learning.
Regards, Andrew

[Jim Yingst]

Additionally I think using CTRL-C for stoping the server is bad, as it's effectivelly a user controlled crash so you lose control of actions that should be carried out when you close down the server, i.e saving the properties file.
Well, the properties file isn't a problem. I already saved any changes when the user hit OK on the GUI, before the server had fully started. (I.e. before the Naming.rebind() which would allow any clients to contact the server.) However you're correct that there may be other issues. In particular, the server admin may interrupt a transaction currently in progress, leaving the DB file in an indeterminate state. If this happens due to power outage, well, there's not much we can do about that unless we commit to building a whole change log and developing recovery procedures, which I think most of us consider to be out of scope for this assignment. But it's true that the server admin might appreciate a nice friendly and safe way to shut down the server, and a permanent GUI would provide a good place to put this. I'll consider this possibility.