Hi, everyone. I am working on setting the properties file. After searching same topics in this forum, I grasp some concepts of this file. Thank you all! There are two questions, 1.Is it necessary to provide the function that the Client/Sever GUI can modify this file? I am not sure whether offering this function is beyond the requirements. For example, a user runs �java �jar runme.jar alone� for the first time. Then a dialog pops up, prompts the user to enter the local db file location. If the location is available, store it in the properties file and make the Client GUI visible at the same time. The GUI has a "configuration" MenuItem, allowing the user to change the property of db file location freely. If so, there might generate some new questions, especially in the Server GUI, say, when a user changes the port property, all connecting clients will only get a RemoteException and not know what happens. The only right thing they could do is to close the Client GUI, modify the port property correctly, and restart the program again. I think this process is redundant and complex. Maybe we should not allow changing any property once the file has been generated. 2.I want to know whether I understand correctly. If I allow �server� mode and �empty� mode run in the same machine simultaneously, there should generate two suncertify.properties files when the directory starting server is different from the directory starting remote client. Is it right? In addition, if I use a separate class to write and read the properties file,judge the mode parameter, what package should this class reside? Client or Server? Either of them seems reasonable.
Thanks in advance! Ailsa Cape [ August 28, 2005: Message edited by: Ailsa Cape ]
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.
So I must configure by the GUI.
As for the second question: I will probably use one properties file per user (in her current working directory) and if necessary have a different prefix (or infix) on the property names for each of the modes.
Disclamer :The above is not a recommendation to you: It's my current approach, which, of course, is prone to change.
Is it strictly necessary to have diff. config for the modes? I have one file, write/read port and/or db to this.
Is this not enough?
Joined: Nov 25, 2004
Hi - this has probably been answered before, but am I correct in thinking that the registry creating/binding e.g. Registry registry = LocateRegistry.getRegistry
should take place within the server code?
Joined: Aug 10, 2005
Thank you, Barry, Samuel, and Lucy. I am back. It took me several days to finish the Deliverables section in my assignment. I use one properties file in the working directory if alone and server mode run in the same directory on the same machine, using different properties names to store the values, such as clientDBPath, serverDBPath, etc. Instead of providing the function that the main Client/Sever GUI modifies the properties file, I do provide same interface, except that a button , say �change�, is visible before a user sees the main Client/Server GUI for 2 times. The button can change the relative properties previously stored in the suncertify.properties file. But I don�t know it is necessary to do so since the instructions simply state that All configuration must be done via a GUI, and must be persistent between runs of the program. It seems this button �change� is unnecessary. Is it right?
Another question, I first implement the alone mode. It directly uses the Contractor class which doesn�t implement Serializable interface. and works fine. The user can update or book a record. But in the server mode, the Contractor class must have the following signature, or the JTable doesn�t obtain any data at all.
If I also use this class in the alone mode, can I break the requirements The program must be able to work in a non-networked mode. In this mode, the database and GUI must run in the same VM and must perform no networking, must not use loopback networking, and must not involve the serialization of any objects when communicating between the GUI and database elements. Or Serializable is just a marker interface, so it only indicates that the class which implements it can be serialized, rather than it actually is. In other words, as long as I don�t use loopback networking, I can freely use the class Contractor which has implemented Serializable interface in alone mode. Am I right? I think my solution meets this requirement, right?
a bit confusing (for me) that you add unrelated questions to a thread named "About the suncertify.properties file". i would propose to open a new thread for your serialization issue... ;-)
i'm at a similar point then you are. first, i didn't really care about settings, now i re-read my instructions and found that quoted phrase about persistent settings.
well, i'm not sure if the db-location is a real "setting". if i open for example a word-processor, i might or might not like the fact that it reloads my last document.
so, the only property i think of being a must to persistant would be the ip of the server. (i dont allow changing port & service name).
so, here's my question:
what settings are all you guys persisting..? did i miss anything?
many thanks, jan
Joined: Aug 10, 2005
Thank you for your suggestion. If no answers for my serialization promblem, I have to open a new thread for this.
In my assignment, the instructions state that The program must allow the user to specify the location of the database., so I think the db-location is a real setting.
The following is my design. In the server mode, in order to start server, I must know the port number and the db-location, the port number is used to registry a RMI service object. In the remote client, users must know the port number and Server machine IP name/address to run the lookup method and obtain the remote object. In the alone mode, the user must know the db-location.