I am close to submit - question about suncertify.properties

[Mike Tilling]

Hi

2- What are the properties that need to go to the suncertify.properties file?

Best Regards

[Oliver Weikopf]

I have:
DB Server (IP or name)
RMI Port
RMI service name
Local Database file

I thinkn that should cover it.

[Ken Boyd]

yes four values

[Jeroen T Wenting]

nope. More than 4
db server and port as well as filename should be separate for server and client modes

I've other stuff in their as well, to control some custom classloading I do in my factories.

[Mihai Radulescu]

Hi guys

I use :

server.port=1099
server.ip=localhost
database.encoding=US-ASCII
database.path=db-1x3.db
database.id=0x103
record.delete=0xFF
record.valid=0


Regards Mihai.
[ June 30, 2006: Message edited by: Mihai Radulescu ]

[Jeroen T Wenting]

#B&S configuration
#Mon May 08 17:45:19 CEST 2006
client.config.datafile=db-2x2.db
client.config.rmi.service=BSDataServer
server.rmi.port=1099
client.config.server=10.1.0.10
client.config.dataclass=suncertify.db.bs.BSDataFile
client.config.searcher=suncertify.client.NameCitySearchDisplay
server.file=db-2x2.db
server.timeout=1
server.rmi.service=BSDataServer
client.config.serverport=1099

That's my file at current. Might put some more stuff in there that is now internal to the application.

[Mihai Radulescu]

Hi Jeroen,

Do you manage all the proeprties with the a configuration UI ?

Regards M

[Jeroen T Wenting]

no.
Of course several are dependent on what the user enters.
But the rest is internal to the application, and of interest mainly to people maintaining it.
In the real world those would of course be in a different file, but as the assignment clearly states there must be only one properties file I don't want to risk that.

[Mike Tilling]

Is it acceptable to store values directly into the suncertify.properties file for example:

c:\\assignement\\fileName
1099

the program take care of the meaning of these values

Best Regards

[Andrew Monkhouse]

Hi Mike,

This would be risky, as there is a rule that the examiner must not need to modify any files in order to run your application. The examiner might take the existance of any parameters that are not modified through the GUI as a violation of the rule. If they aren't there to be modified, why are they there?

Also, the properties file may not exist when your application is started - have you taken that into consideration?

Finally - it may be just your examples, but that is not the normal format of a properties file. It would be dangerous to manually add or edit a properties file given that it could break the ability to read the file in the standard manner.

Regards, Andrew

[Mike Tilling]

Thanks Anderwew,

-What I wanted to say in my quetion is :

When my application store the variables into the suncertify.properties file, does it have to mentionne the name of the stored variables as well, say I decided to store the sever name and the rmi port number in the suncertify.properties file, can I store them like that:

localhost
1099


when the application reads from this file, it will know that the first value is for the server name and the second value is for the rmi port number

In other term, does the suncertify.properties file have a specific format:

say "variableName : variableValue", in other words what format the suncertify.properties should have

- When the application update the suncertify.properties file?, is it at the exit of the application? or directly when each variable (that need to go into the properties file) is getting changed.

[Mihai Radulescu]

Jeroen,

But the rest is internal to the application, and of interest mainly to people maintaining it.

If the "maintaining people" must edit the configuration file then you are a little bit against the specs (at least mines).

All configuration must be done via a GUI, and must be persistent between runs of the program

Why you do this ?

Regards M.

[Daniel Dalton]

Hi Mike

You're probably well aware of this anyway, but a properties file has a standard format - namely

 
key1 = value1 
key2 = value2

That's why people have given examples in that format. Take a look at the documentation for the java.util.Properties class which is designed to work with Property files.

Regards, Dan

[Andrew Monkhouse]

Hi Mike,

I think Dan said it best.

Remember that there is the following statement in the instructions:

Use of functionality provided by the core Java classes will be preferred to your own implementation of that functionality, unless there is a specific advantage to providing your own implementation.

So you would need to show a specific advantage for your non-standard way of doing things rather than using the Properties class.

Regards, Andrew

[Jeroen T Wenting]

If the "maintaining people" must edit the configuration file then you are a little bit against the specs (at least mines).

Not really. Those are people expanding the application, programmers who come after me
Unless you think the criterium that the application should be easy to expand upon means you have to write a complete Java IDE as part of the assignment as well I don't think it's a problem those people should have to change the file by hand

[Oliver Weikopf]

Originally posted by Jeroen T Wenting:
nope. More than 4
db server and port as well as filename should be separate for server and client modes

You've got a point about the rmi port and service name (which is what you mean by "server", right?)
But the client mode does not use a db file, so it needs no filename.
Is this for the standalone version rather than for the client version? If so, why should that use another db file than the server?

[Mihai Radulescu]

Hi Jeroen

Those are people expanding the application

Interesting point of view. I'll think about it.
What criteria you use to differ between the application configuration and the expanding ? Can you give an example ?

Regards M.

[Mike Tilling]

Originally posted by Daniel Dalton:
Hi Mike

You're probably well aware of this anyway, but a properties file has a standard format - namely

 
key1 = value1 
key2 = value2

That's why people have given examples in that format. Take a look at the documentation for the java.util.Properties class which is designed to work with Property files.

Regards, Dan

Thanks

I wrote a program that uses an object of java.util.Properties class, I used setProperty and getProperty methods to store the variable values within this object, at the exit of the application, the Properties type object is stored within a file (suncertify.properties) using ObjectOutputStream, when I run the program for a second time, I will have the error "Unkown source type" when I try to get the variables values using getPropert() method,
what 's wrong with my program?
do I have to change the manner I am managing the suncertify.properties file with?

Best Regards

[Jeroen T Wenting]

Originally posted by Oliver Weikopf:


You've got a point about the rmi port and service name (which is what you mean by "server", right?)
But the client mode does not use a db file, so it needs no filename.
Is this for the standalone version rather than for the client version? If so, why should that use another db file than the server?

the client needs to be able to run in either standalone mode or as a network client, so it needs both network information AND a filename (though not at the same time).

[Jeroen T Wenting]

Originally posted by Mihai Radulescu:
Hi Jeroen



Interesting point of view. I'll think about it.
What criteria you use to differ between the application configuration and the expanding ? Can you give an example ?

Regards M.

Classnames to be used in reflection are clearly something the user of the application should not need to worry about.
But someone creating a search screen with more options would want to be able to get his users that screen with minimal effort.
By setting the classname in the configuration all he needs to do is distribute an updated properties file, an updated startup script/batchfile (not required for the assignment but would be used in a production environment of course) and a jar containing the new screen.

Servicename is similar. By making that flexible in the properties file the system administrator could change it by distributing some new files.
Could be handy if the same application were to be used for different departments (maybe several branches each using the same server machine with a different instance of the server software).

[Mihai Radulescu]

Hi Jeroen

The Classnames and Servicename are very useful tips, thanX.

Ah, I have one(two or more) more questions
your :

client.config.dataclass=suncertify.db.bs.BSDataFile

is your "raf" class, used to access physic the records ?

and the :

server.rmi.service=BSDataServer

is your binding name ? If yes Why you need to change/manage this information ?


Regards M.
[ July 04, 2006: Message edited by: Mihai Radulescu ]

[Jeroen T Wenting]

1) yes, that's the class that actually reads and writes the file. It's the only entry point in the server itself that's specific to the file format (it does have some helper classes).
Everything else uses either nothing at all from that tree or uses it through public interfaces only, never through implementation classes.

2) as I said, that allows administrators to potentially run multiple servers on the same machine, using only different service names.
In combination with different file access classes that means they can change the entire server to use a different data format by just supplying a jar with the new classes and a modified properties file.