Methods to implement suncertify.properties

[Richard Jackson]

Hello,every one
In my assignment,there are following statements:

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.

Although many people have posted the same topic,but I am still confused about several points.
1)The properties file may be write like this,

import java.util.*;
import java.io.*;
public class TestPropertySetting{
public static void main(String[] args){
try{
Properties settings=new Properties();
settings.put("DBLocation","localhost");
settings.put("Address","http://127.0.0.1");
settings.put("Port Number","1099");
settings.put("Database File Name","db-1x3.db");
FileOutputStream out=new FileOutputStream("TestPropertySetting.properties");
settings.store(out,"Configuration Information");
FileInputStream in=new FileInputStream("TestPropertySetting.properties");
settings.load(in);
Enumeration enum=settings.propertyNames();
while(enum.hasMoreElements()){
key=(String)enum.nextElement();
System.out.println(key+ "="+
settings.getProperty(key));
}
}catch(Exception e){}
}
private static String key;
}  

If it hasn't to have a default setting,instruction.html imply that I should configure all parameters into the property file in GUI.
2)When I store them and make them effective,is that the moment I click the OK button?
3)I must read file name and location from the property file?
Regards, Richard

[Jim Yingst]

}catch(Exception e){}

No. Bad. Wrong. Never. Evil.
As for other questions:
(1) Ummm... is there a question?
(2) Correct, when the user presses OK on the GUI, that's a good time to save the values to file.
(3) Yes, and also allow the user to edit these values using the GUI.

[Andrew Monkhouse]

Hi Richard,
In addition to Jim's comments, I would invite you to consider using the FileOutputStream's close() and/or flush() methods, (and the close() method of FileInputStream). In general you should not keep a file open for any longer than absolutely necessary - you are holding a system resource unnecessarily, and there is always the possibility in the code you have that the OS will just buffer the results of your write to file so the read may not work.
Also, I don't think you want the address to have a "http://" protocol identifier.
Regards, Andrew

[Richard Jackson]

Hi,Andrew

I would invite you to consider using the FileOutputStream's close() and/or flush() methods, (and the close() method of FileInputStream).

Yes,I agree to use close()/flush() method to release system resource.

Also, I don't think you want the address to have a "http://" protocol identifier.

Actually,I am not very clear whether I need use the "http://" identifier.
If involving a URL address,I think,it should be used.
Each client must enter server address(like "http://192.168.1.x") and port number(like "1099" )?
I have to other exercises to test.
Regards, Richard

[Andrew Monkhouse]

Hi Richard,

Originally posted by Richard Jackson:
Actually,I am not very clear whether I need use the "http://" identifier.
If involving a URL address,I think,it should be used.
Each client must enter server address(like "http://192.168.1.x") and port number(like "1099" )?

But don't you have a requirement that you may not require the use of a web server? In which case, using a protocol associated with the web is probably not a good idea.
I would think an RMI protocol might be a better idea. E.g. "rmi://127.0.0.1"
Regards, Andrew

[Richard Jackson]

Yes,Andrew.
In my instructions.html file,there is a sentence:

Restrictions on RMI
You must not require the use of an HTTP server.

I don't exactly need Web server,so I may use "rmi://127.0.0.1".
And then I try it.
Regards, Richard