(NX:URLyBird)A question about properties files:

[biang lin]

Hi,
Did you guys put all configurations into one single properties file?
There's two kind of configurations: for server side and for client side.
So should I make two properties files for server side and client side respectively?
Another question:
When an unreferenced method is called,can this remote object be garbage collected some time later?
And what configureations should be put in the properties file?
I have only two properties:"server url" and "client number",what else??
[ August 08, 2003: Message edited by: biang lin ]
[ August 08, 2003: Message edited by: biang lin ]

[Andrew Monkhouse]

Hi Biang
I think you have the instruction "configuration information must be stored in a file called suncertify.properties". So therefore you have to allow for the case where server information and client gui application may be in the same file, and may be different information.
By different information, I mean it is possible that the server will have the servername set to "localhost" while the clients may have it set to a specific hostname or ip-address. Or the server may have the database location as "/shared/scjd/db.db" while the clients have it set to "S:\scjd\db.db". You can possibly think of other cases where the client and server have different values for the same field.
So you may need to think about how to keep the client and server values different even though they share the same file. You may also need to think about how to have both client and server application writing to the same file without destroying the other's data.
Anyone else have opinions on this?
Regards, Andrew

[biang lin]

Hi Andrew,
Thanks for your comment.
But my instructions say "All configuration must be done via a GUI, and must be persistent between runs of the program."
That means server configuration should be done via Client GUI, so a user can change server configuration, I think this is not reasonable.
Or there is a "server GUI" to change server configuration?
What do you say?

[Andrew Monkhouse]

Hi Biang
I think you can have a GUI configuration screen for the server. After all, you may need to enter the location of the database file, and what port number your rmi registry is running on. It would also be nice to give a "shutdown" type of button for the server.
Regards, Andrew

[Nick Lee]

Hi,
I think only one file is enough,you can keep all the info(params) inside it.I've finished working on that function and it works well.
hope helpful.

[biang lin]

Hi Andrew,
I think your comment is reasonable for this assignment.
But,suppose in practice,any client can control the server,is this nice?

[biang lin]

Originally posted by Nick Lee:
Hi,
I think only one file is enough,you can keep all the info(params) inside it.I've finished working on that function and it works well.
hope helpful.

Hi Nick,
I think you are right.But where did you configure the server?
[ August 10, 2003: Message edited by: biang lin ]

[Andrew Monkhouse]

Hi Biang
I was talking about having a GUI for the server. Not having the client control the server.
Regards, Andrew

[biang lin]

Originally posted by Andrew Monkhouse:
Hi Biang
I was talking about having a GUI for the server. Not having the client control the server.
Regards, Andrew

Hi Andrew,
OK,I think understand you now.
Suppose there is an administrator who can control server using a server GUI and a user can access server using a client GUI.
Right?

[biang lin]

Hi Andrew,
I have another question:
There is only one db file,so the db file location can be modified by server GUI and also by client GUI. What if they choose the different location??

[Nick Lee]

Hmm,I think the location doesn't need to be configed,cos ur db file should be placed beside ur jar file,so,only file name,server port and server ip should be configed(my oponion).

[biang lin]

Hi Nick,
I like your opinion, I don't need to make a FileChooser in this way.

[Andrew Monkhouse]

Hi Biang & Nick

Biang: There is only one db file,so the db file location can be modified by server GUI and also by client GUI. What if they choose the different location??

Then you have to be able to store two different database locations in the properties file: one for the client and one for the server.
This is fairly unlikely though: if the server is running, the client should not be running in stand alone mode.

Nick: I think the location doesn't need to be configed,cos ur db file should be placed beside ur jar file

This implies a different problem: you now have to worry about where your jar file is stored. This can be worked out programatically with a little bit of thought.
The instructions tell us that the properties file has to be stored in the current working directory, which implies that it is possible that the user may start your application from a different directory to where your jar file is in. Such as:

c:\temp> java -jar c:\scjd\runme.jar

Regards, Andrew

[biang lin]

Hi Andrew,
"The instructions tell us that the properties file has to be stored in the current working directory, which implies that it is possible that the user may start your application from a different directory to where your jar file is in. Such as......
"
I don't know what do you mean.
So what's wrong if I don't allow user to configure db file location??

[Andrew Monkhouse]

Hi Biang,
Nothing is wrong.
But you have to find the database file programatically. In the example I gave above, the current working directory will be c:\temp. But the database will be in c:\scjd. As long as you find it there, you are OK.
Regards, Andrew

[biang lin]

Hi Andrew,
I see.
I got confused about " current working directory ".
I thought "current working directory" is always the directory where the main class or jar file in.
Thanks a lot.

[Vlad Rabkin]

Hi,
I store all properties in one file suncertify.properties, which is located in the current directory (directory where the jar file is located).
Client GUI & Server GUI are used to confiogure this properties.
Vlad

[Andrew Monkhouse]

Hi Vlad
According to the instructions, "Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory."
This may be the same directory that contains the jar file, but it doesn't have to be. The example I gave was one instance where the current working directory would be different from the directory where the jar file is located.
Are you storing your properties file in the current working directory or are you explicitly storing it in the same directory as the jar file?
Regards, Andrew

[biang lin]

Originally posted by Andrew Monkhouse:
Hi Vlad
According to the instructions, "Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory."
This may be the same directory that contains the jar file, but it doesn't have to be. The example I gave was one instance where the current working directory would be different from the directory where the jar file is located.
Are you storing your properties file in the current working directory or are you explicitly storing it in the same directory as the jar file?
Regards, Andrew

Hi Andrew,
You mean the properties file's directory depends on the current working directory.
So the properties file's directory will be different when the user change the woking directory.
So my program must copy the properties file to the current working directory each time the program start.
Am I right?

[biang lin]

Another question:
This is from my instructions:
"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. "
So I think there will be two ways to start the program:
1: Start with the mode flag "server",and then start with mode flag left out entirely. This is the remote mode.
2: Start with the mode flag "alone". This is the local mode.
Am I right?
[ August 12, 2003: Message edited by: biang lin ]

[Vlad Rabkin]

Hi Andrew,

Are you storing your properties file in the current working directory or are you explicitly storing it in the same directory as the jar file?

My jar is in the current directory.
So,
I am storing my properties file in the current working directory which is the same directory as the jar file is.
Instance:
d:\...\run
dir
suncertify.properties
runme.jar
db.db
...
Vlad

[Vlad Rabkin]

Hi Andrew,
Of course if runme.jar will be executed from another directory(not the directory where runme.jar is located):
- properties will not be found if you try to load them
- properties will be saved in that directory (where the programm was executed), but not where runme.jar is.
So, you are right.
Vlad

[biang lin]

Originally posted by Vlad Rabkin:
Hi Andrew,
Of course if runme.jar will be executed from another directory(not the directory where runme.jar is located):
- properties will not be found if you try to load them
- properties will be saved in that directory (where the programm was executed), but not where runme.jar is.
So, you are right.
Vlad

Hi Vlad,
But when the program shut down,where do I save the properties file to??
Must I save it to the directory where the jar file located?

[Andrew Monkhouse]

Hi Biang
No, you only need to save it to the current working directory.
Regards, Andrew

[Vlad Rabkin]

Hi,
I agree with Andrew.
It doesn't matter where is jar file. You load and save properties in the current working directory, which is the directory where you have started your application.

Vlad

[biang lin]

Hi Andrew and Vlad,
What if the user change the current working directory next time he start the program? Where can the program find the properties file?
Therefor, I think, properties file must be stored at directory where the jar file located when the program shut down, and must be copy to the current working directory next time the program start.
[ August 13, 2003: Message edited by: biang lin ]

[Jim Yingst]

What if the user change the current working directory next time he start the program? Where can the program find the properties file?
What I do is, I just look for the file in the current directory. If it's not there, I assume it's a new user, and I create a new properties file for them. They will need to configure things like host name and port number, using the GUI configuration tools.
This setup allows multiple users on the same machine using the same shared jar file but different properties files. This makes a lot of sense if the users have accounts on a Unix server - each user gets their own loging directory, from which they can start the client program.

[biang lin]

Hi Jim,
I think your comment is reasonable,thank you very much.

[biang lin]

Originally posted by Jim Yingst:
What I do is, I just look for the file in the current directory. If it's not there, I assume it's a new user, and I create a new properties file for them. They will need to configure things like host name and port number, using the GUI configuration tools.
This setup allows multiple users on the same machine using the same shared jar file but different properties files. This makes a lot of sense if the users have accounts on a Unix server - each user gets their own loging directory, from which they can start the client program.[/QB]

Hi Jim,
So what if the server program and the client program are started from different working directory??
Maybe I think too much.

[Vlad Rabkin]

Hi,
I think we just have to follow the requirements: property file must be located in the currect directory (no matter where the jar file is).
While loading properties if no properties file is found, I set up default properties and save them in the file. I guess it already more then required.

Vlad

[Jim Yingst]

So what if the server program and the client program are started from different working directory??
That's fine. They can function as two separate programs, with two separate properties files, which could be completely different. Perhaps there's more than one server, and the user really wants to connect to a server on a different machine, not the one on the same machine? The client gets to choose what he connects to; if he wants to connect to the server on the same machine, he needs to make sure his connection info is set up correctly, e.g. the port number needs to be the same.

[biang lin]

Hi Vlad and Jim,
Thank you very much.
I will think carefully and make it clear.