This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I would like to have your opinion on the following.
In my instructions (B&S 2.1.1) I read :
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.
In my interpretation this is only meant for the client program since according to the rest of the instructions we do not have to provide a GUI for the server program. I have always thought a server 'd rather not depend on a GUI and that it even should run on machines without any windowing system.
So I assumed there was no GUI needed for the server, and I provided the defaults for the RMI registry port and the database file location in a separate suncertify.server.properties file. As long as the server administrator runs the server from the defaults, he will not need to edit this file (which I think matches the 'must' requirement of no need to edit any properties files). If he wants something non-default, he will have to edit the properties file. He stops the server is with a CTRL_C. JVM Shutdown hooks are provided to clean up all connections nicely and give some feedback messages in the console.
Maybe I have understood this wrong ? Have you ever heard of anymone automatically failed because of using another properties file for the server program and not using a GUI for server configuration ?
I have almost finished my assignment, and I would like to clear this out before I submit.
I am still working on my project, but your alternatives sure look very dangerous, since they go against many "must"s. For example, my spec states that we may (must?) not ask the examiner to edit any file. It also talks about using just one properties file and always using GUI for configurations, as you quoted.
IMHO, if a must does not include restrictions, then it applies to all (absolutely everywhere possible).
I know GUI interface may not be a good thing for servers, but remember: specification always has the final word.
I would like some nice and easy admin GUI for most servers myself. [ March 20, 2006: Message edited by: Eiji Seki ]
1, They expect a file called suncertify.properties, not others. 2, You MUST not require manual editing of any files by the examiners.
SCJP, SCJD, SCEA
Joined: Dec 23, 2005
Originally posted by Hans Crol: As long as the server administrator runs the server from the defaults, he will not need to edit this file (which I think matches the 'must' requirement of no need to edit any properties files).
If he wants something non-default, he will have to edit the properties file.
Don't you think that the 'must' requirement of no need to edit any properties files applys to non-default?
I'd be very carefull about your use of defaults. What if the default port you've set in the file is already in use - you will only be able to change it by editting the file manually which breaks the "must" requirement, and if you don't your server won't run. I provided a simple GUI for my server which allowed you to specify the port and file location and start the server.
I'd make sure about the values in your suncertify.properties file. Maybe your assignment is different but in my URLyBird assignment (and most others that I've read) the remote local flag is passed in as a command line parameter. The values required in the properties file are things like database file location and RMI server port.
Joined: Mar 18, 2006
You are right, one can not assume the defaults will always work.
OK, guys I am convinced, not using a server GUI and using a separate server properties will lead me into trouble. Going to do a little rework before I submit ... Thanks for your comments.
Joined: Feb 16, 2006
thx for your comments.
i have made changes that are more in keeping with the Requirements Document.
Joined: Feb 15, 2006
Don't rework. Try to elaborate your solution, research it, design it and ask questions to yourself or to this forum before implementing. Just an advice.
Joined: Feb 16, 2006
I just added (and learned about!) an Adapter or Facade class.
Simplified things greatly.
Just a simple starter class / GUI that gets the port / dbname from the user and writes them to the suncertify.properties file.
the text fields are loaded with the existing values. so the user has the option to use the default settings (most likely) or to enter in new values.
I've chosen to allow both options. If the machine on which the server is run has the capability, a GUI is displayed with the values from the properties file as a default. It waits for the user to activate the server after possibly changing the values (at which time those are then written to the file as the new defaults). If no graphical capabilities exist, the server starts in headless mode reading the properties file to load its settings. In that situation there is no user interaction at all.
This second goes beyond the requirements of the assignment which clearly states a GUI is required (and thus assumes the machine on which the server will run has the capability to display it), I included it primarilly to enable me to test the server on a remote machine without having to walk over to start it, instead running it from a telnet connection.
I add add my to cent here. I agree with Jeroen, in my case (URLy) I have a server UI but this UI does nothing more than to send commands to a ServerHandler. The handler uses a Map of properties, this map comes : 1.from the server UI (and here the user can change some properties) if the UI is possible 2.from the properties file (suncertify.proeprties)
If the server system does not allow a UI then I think that is reasonable to edit the properties file by hand. In one of by early version I have a remove UI for server but this goes over the certification purposes(it also makes the code more complex and heavy to understand and ...).