Default Properties

[mike acre]

There are two ways to go with this.
That is what happens when either the file 'suncertify.properties', or one of the key/value pairs therein, is missing.

1/ Hardcode defaults and use them to replace missing values or write a whole new file.

2/ Have an 'untouchable' properties file inside the Jar.

Andrew favours the former: here

I favour the latter.

java.util.Properties is set up better for the latter.
Imagine a getProperty() call.

Get property from Properties object.
it is not there, null returned.
get it from defaults, oh need an internal hashMap of defaults.
Pain!
Even if you validate all properties on initial read you have similar problem.

Seems to me if you go with the defaults in the Jar then the coding becomes much simpler.

Thoughts please.

[Hanna Habashy]

hi Mike,
First, what did you store in the properties file that is so fatal and a must to have?
In my properties file, the most important key was the magiceCookie value, and the default server database file location. At startup, I check the properties file, if it is there, I read it, and if it is not there, I reintialize it from the original DB file.
Other keys are associated with individaul users. Such as, last file opend, server IP address...etc
Also, I implemented an administartive funcion to restore the default properties file, which contains the MagicCookie value only.
[ August 02, 2004: Message edited by: Hanna Habashy ]

[mike acre]

Originally posted by Hanna Habashy:
hi Mike,
First, what did you store in the properties file that is so fatal and a must to have?

Well you must have some value, and if you can guarantee there is a default value, as you can with a properties resource internal to the Jar, it makes the coding simpler, no more checking if null, no need to keep hardcoded values and locate them. Simply load up and forget about it.

[peter wooster]

Originally posted by mike acre:
...
2/ Have an 'untouchable' properties file inside the Jar.

Andrew favours the former: here

I favour the latter.

java.util.Properties is set up better for the latter.
Imagine a getProperty() call.

Get property from Properties object.
it is not there, null returned.
get it from defaults, oh need an internal hashMap of defaults.
Pain!
Even if you validate all properties on initial read you have similar problem.

Seems to me if you go with the defaults in the Jar then the coding becomes much simpler.

Thoughts please.

What I do is to read in the defaults first and then read in the specific properties. This also makes a "reset all to default" option possible. Here's an example of the code:

import java.io.*;
import java.util.*;
 
public class TestProp{
    public static void main(String [] args){
        new TestProp().start();
    }
 
    private void start(){
        Properties prop = new Properties();
        InputStream defIn = null;
        InputStream propIn = null;
 
        // first load in the defaults
        ClassLoader loader = this.getClass().getClassLoader();
        if(loader != null){
            defIn = loader.getResourceAsStream("default.properties");
            if(defIn != null){
                try{
                    prop.load(defIn);
                } catch (IOException e) {
                    e.printStackTrace();
                }
            } else {
                System.out.println("default properties not found");
            }
        }
 
        try{
            propIn = new FileInputStream("test.properties");
            prop.load(propIn);
        } catch (FileNotFoundException nf) {
            System.out.println("program properties not found");
        } catch (IOException e) {
            e.printStackTrace();
        }
 
        Enumeration props = prop.propertyNames();
        while (props.hasMoreElements()) {
            String key = (String)props.nextElement();
            String value = prop.getProperty(key);
            System.out.println("property "+key+"="+value);
        }
    }
}

[mike acre]

Originally posted by peter wooster:
What I do is...

Yes, exactly what I'm doing.

You can get resource as stream directly from Class:

getClass().getResourceAsStream(...)

[Hanna Habashy]

mike,

Well you must have some value, and if you can guarantee there is a default value

What default value do you garantee??
The magic cookie value, and the db location can be changed by the admin..

I don't know about your design, but in my project, everything can be changed. The server db file, the local db file, the location of the server db file, even a db file itself. It can contains differnt number of attributes per record.
Everything is done dynamically at runtime.

[mike acre]

What default value do you garantee??
The magic cookie value, and the db location can be changed by the admin..

The way Peter (it seems) and I are doing it, is to have a guaranteed set of defaults, this guarantee is as good as it gets.
But these are ONLY defaults, there is another set, the suncertify.properties file that 'can' be edited manually or is updated during gui use.

The advantage of this is that it makes it easier if suncertify.properties is missing or incomplete.

To fully benefit from the code simplicity I will have to add this to the user guide:

The suncertify.properties file is updated via the gui for all values and these values are validated. When validation fails the value is replaced with a default. However it is possible to edit the file directly, and whilst this is okay, no validation is done and the application may fail unexpectedly. If this occurs delete the file, and restart, defaults will be used and the file recreated.

[Wickes Potgieter]

What about text for labels, error messages, etc. where do you put yours? in the properties file or do you hard code them in your source?

[Yanxin Zhao]

Hi:
How to write key-value into which text file?

[Omar Kalaldeh]

Here what I am going to do at my server,

If there is any missing data from the properties file the server will not run and require the user to fill that property using config GUI.

I think this a good handling, and that is how most servers work.

[Hanna Habashy]

Wickes,

What about text for labels, error messages, etc. where do you put yours? in the properties file or do you hard code them in your source?

Text message and errors are hard coded. I don't see any benefits of putting this messages outside of the code. When a developer throw an exception with appropriate message, that message meant something to that developer. The developer attempts to say what happen. I found that message belong to the code, and should not be changed, unless the code itself is changed.
Same argument apply to lables. If the develper create a button to sumbit a form, and called it "Submit", I found it inappropriate to change it to anything else.
I use property and configuration files to configuer the program at runtime. It contains information that change according to the user, the customer or the deployer.
If I put this data in a property file, then I am openning a window for someone to change what it meant not to be changed.
This is my own opinion in design. I know many people will disagree with me, however I found this technique very secure.

[Richard Jackson]

Hi,Hanna

Many people think that the program need comparing the property value with that of properties file, like magic cookie.

If I put this data in a property file, then I am openning a window for someone to change what it meant not to be changed.

Did you ever put some data in your property file?
For instance, you are able to put magicCookie/numFields/fileName values into it before the property file was created?

I know many people will disagree with me, however I found this technique very secure.

Maybe your design thought is efficient,I think that's true.
But why is this kind of mechanism secure as you said?

Thanks for your comment.

Regards, Richard

[Hanna Habashy]

Hi Richard,

Did you ever put some data in your property file?
For instance, you are able to put magicCookie/numFields/fileName values into it before the property file was created?

No.
The only thing I need for the program to startup for the first time is that the given db file must be in the same working directory. The first time the program startup, it will look for the default db file name-hard coded- in the current working directory. It reads the magic cookie value, and then create the properties file.
I don't care for the number of fields, becasue my design will function with any db file that adhere to the given schema. Even in my GUI, the number of fields created is always created at runtime.
Once the server start for the first time, the adminstrator-through admin window- can change the defualt db file name and location, and then it is stored in the properties file. At any time, the admin, also, can restore the defualt properties- in this case the defualt db file name.

why is this kind of mechanism secure as you said?

I believe it is secure becasue there is no way to corrupt the program. If the properies file is deleted or corrupted, just restart the server. Also, there is no window from any one to change any of the errer codes, or the message that the program use.

The only requirments in the program specification is that the original db file must be in the current working directory, and this is the only thing I require to start the program for the first time.
[ August 17, 2004: Message edited by: Hanna Habashy ]

[Anton Golovin]

I my design, should the suncertify.properties file be missing at startup, it is created:

1) if GUI networked by specifying connection properties by user.
2) if server by specifying db file location by user.
3) if GUI by specifying both

Therefore, the best way to do so is at startup within the Factory class you use to run the right program.

[Richard Jackson]

Hanna and Anton, thank you.

I'll try again and verify that of validity.

Regards, Richard

[Richard Jackson]

Hi,Hanna and other experts

At startup, I check the properties file, if it is there, I read it, and if it is not there, I reintialize it from the original DB file.

I try to explain its meaning that Hanna said,and write pseudocode:

// start the main program and check property file
if(property file exists){
     open the data file;
     //do other database operations 
     ...
}else{
     create a property file;
     write magic cookie into the file;
}

But I have two problems,
1) Should I specify the current path of the property file?
2) If the code above is correct,is this right that I start the main program through command line argument "alone" or "server"?

Thanks.

Regards, Richard

[Hanna Habashy]

Richard,

1) Should I specify the current path of the property file?

I do that, because I allow the admin to change the path of the db file on the server, although It is not required to do so.

If the code above is correct,is this right that I start the main program through command line argument "alone" or "server"?

If you follow the direction you provided, you must start you server program first. The server program is the one which initialize the magic cookie value, which is used in the client program to varify the validility of a file.
YOu should not initialize the properies file through the client program, because you cannot assume that the original db file, which is used only by the server, is on the client machine.

[Richard Jackson]

Hi，Hanna

I attempt to make the program use specified property file when the program starts.Base steps I assumed like this:

1)Start main program with appropriate mode flag;
2)If starting the server GUI,and then open the specifed data file;
3)As the moment,the action wrapped by event listener try to read the property file. If it does not exists,the program create a property file;
4)Reading cookie of file header from data file if the file is valid;
5)Finish opening data file and save properties into previous created property file;
6)Continue excuting other data access functions ...

Anyone has any suggestions? Please correct and criticize for me.

[Anton Golovin]

My project has the following:

Upon the very first run of the program, properties file does not exist. It should not be pre-installed.

1) networked GUI design: looks for properties file and connection properties in it, if not, prompts user to configure connection properties, and, upon ascertaining the properties are well-formatted, commits them to the properties file.

2) local GUI design: looks for properties file and datafile path in it; if not, prompts user to locate data file and, upons ascertaining it is a data file, logs the path into the properties file.

3) server design: looks for specified path in properties file; if not found, looks for default data file in the current working directory; if not found, prompts user to locate the data file and, upon ascertaining it is a data file, logs the value into the properties file.

It ascertains the file is a data file by proxy: if the data-management system starts up fine, then the file must be a data file. The actual checking is done in the Schema class where the class verifies that the file cookie value is the expected one.

suncertify.properties fields:

rmi_network_path
rmi_object_name
datafile_path_and_name

I think this is all that is needed.
[ August 21, 2004: Message edited by: Anton Golovin ]

[Hanna Habashy]

Richard,

Anyone has any suggestions? Please correct and criticize for me.

I think your algorithm is fine.

Anton,

local GUI design: looks for properties file and datafile path in it; if not, prompts user to locate data file and, upons ascertaining it is a data file, logs the path into the properties file.

This is what I understood: If the program in client mode and the properties file doesn't exist, the user can configuer the required data and then log it to a newly created property file.
If I understand you correctly, how will you varify that a local file is a valid db file? Don't you need the magic cookie value to do that?
[ August 23, 2004: Message edited by: Hanna Habashy ]

[Anton Golovin]

I hardcode the cookie value into my Schema class. Schema is not visible outside of package suncertify.db. By default, if the data-management system starts, then the file passed in must be a datafile. I don't know if that's the best way to do it, but it seems to work ok.

Alternative way would be to put cookie value into the properties file. But the way I read the problem, the properties file must not be in existence the first time the program runs.

Please correct me if I am wrong.
[ August 23, 2004: Message edited by: Anton Golovin ]

[Hanna Habashy]

Anton,
I think you have a valid approach as long as you can justify it in your choice document.
However, your design makes tight couupling between your software and the original db file. What will happen if the company decided to operate on a different dababase file, with differnt magic cookie value?
[ August 23, 2004: Message edited by: Hanna Habashy ]

[Andrew Monkhouse]

Hi Hanna,

Originally posted by Hanna Habashy:
However, your design makes tight couupling between your software and the original db file. What will happen if the company decided to operate on a different dababase file, with differnt magic cookie value?

Personally, I think that this is an argument for hard coding the magic cookie value. If the company chooses to use a different database file, then they should either choose to use the same database format (in which case they should use the same cookie), or they can use a different database format (in which case they should use a different cookie).

To give an explicit example, the schema description section of my instructions states (in part):

Repeated for each field in a record: 
2 byte numeric, length in bytes of field name 
n bytes (defined by previous entry), field name

Having a 2 byte numeric value preceeding the real value enables me to use one specific method which will read the field name without requiring me to worry about the field size. But I know that other candidates have been given assignments where the length is given in a 1 byte numeric value. So they must explicitly write code to handle the field size.

Now imagine if our data files were swapped? The code I wrote will not be able to read their data file and the code they wrote would not be able to read my file.

This is where the magic cookies come in. As long as I have the correct cookie value, I know I can read the data file. If the magic cookie is wrong, then there is a strong probability that I cannot read the data file. It is all magic!

Regards, Andrew

[Mogens Nidding]

I wonder if dealing with an absent properties file is "overdoing it" such that you can lose points for it. Robustness against missing files is not a requirement, and according to the instructions, "You will not receive extra credit points for work beyond the requirements of the specification", but rather, "... marks are awarded for a clear and consistent approach, rather than for any particular solution". And my consistent approach is to not provide robustness.

I coded my persistent configuration in much the same way as was suggested here: 1) Load hardcoded defaults, 2) override with values from suncertify.properties if possible, 3) show GUI for editing properties, 4) Store back to disk. Problem is that I even protect against wrong values (such as a string where an integer is expected)... just couldn't help putting a little robustness in there!

Is there a need to worry?
[ September 29, 2004: Message edited by: Nicky Bodentien ]