B&S suncertify.properties

When I launch the server, I prompt the user to enter Port Number and DB Name if a suncertify.properties file does not exist.
If it does not exist, I store this connection information in suncertify.properties file, So it will be there in future.

When I launch the client, I need to ask for Host Name & Port Number of Server to connect to. Should this dialog appear and prompt the user every time I launch a client, Or should it be persisted in the same way as the server properties file?

If it should be persisted for each client, What should the file be called?

you should ALWAYS prompt for both client AND server, and display the values persisted in the properties file if those are available.

So, does this mean that you store the client properties AND the server properties in the suncertify.properties file?

Yes, you'd probably store both client and server properites in suncertify.properties. Bear in mind though that the idea is that you'd be running client & server on separate machines. That means that on any particular machine you'd only have either one or the other in the properties file. That's what I did anyway.

Hi guys

I don't agree with Jeroen

you should ALWAYS prompt for both client AND server, and display the values persisted in the properties file if those are available.

IMHO you don need ask for the configuration information(like server port and host) if this information already existing (they are already defined or are loaded from the properties file). In my specification I have something like :

Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory.

That means the you configure only once and after this the configuration is loaded from its persistent form (the properties file). You may alter the configuration with a GUI and save the changes.

I have the same dilemma : What I do if the suncertify.properties is missing ?

I have two scenarios :
1.I inform the user about (a pop up message box) and I let the user to call the configuration UI (the configuration UI is an extra dialog - it can be call using the menu or a special button). The user can take some configuration decision or not but if the user choose to ignore the warning the server (or client) UI signals a error in configuration by any action(by action I mean start the server - on server side or search, book on the client side).
2.I build the UI(client or server) and I display the configuration UI - in this way the user must take some configuration decision.

To make the whole stuff more easy every time when the configuration UI is showed (and the configuration file is missing) it contains some default values(by example for server port : 1099 or for host : localhost)

Regards,
Mihai

I am on the B&S project, too. The answer is "NO." Please do NOT prompt the user every single time. I have a line in my instructions.html that reads:"All configuration must be done via a GUI, and must be persistent between runs of the program." I only prompt the user for config info at most once per mode per working directory.

My suncertify.properties has 4 possible elements (ipaddress of server, port number holding the RMI service, the RMI Service name, and the concanical path-filename to the DB).
Some people have gotten away with only using 3 of these elements, assuming that port number 1099 is always available on the assessor's machine. Good luck with that.

In my opinion, all 3 modes of your program should account for the suncertify.properties being in 1 of 4 possible states:

- nonexistent (first time running any mode in current directory)
- partial (1) (only client mode has already run in current directory, we are basically missing the db path)
- partial (2) (only alone mode has already run in current directory, we only have the db path, but not the first three elements)
- complete (the most ideal - where all four elements already exist in the suncertify.properties file. e.g. you have already run server mode, which requires everything, from this working directory).

So I made a 3 X 4 matrix and just tested all of the possibliies.

I hope this makes sense.
[ May 30, 2006: Message edited by: Bob Nedwor ]

IMHO you don need ask for the configuration information(like server port and host) if this information already existing (they are already defined or are loaded from the properties file). In my specification I have something like :

If you don't prompt for the info anyway, how can the user change the information without the application first connecting (or the server launching)?
At the very least that's not a userfriendly option (maybe you can include a toggle and make the application start with the presets next time if it's turned on), at worst it could be an automatic failure because you don't allow the user to change the settings inside the application before connecting.

Hi Jeroen,


Each application mode(server,client and standalone) has it own configuration file.
Lets take the server UI. Using it the user can start,stop or configure (the server). If the configuration file is missing the user is inform about it, so he can configure the server or it can ignore the warning and start the server BUT in this case an other warning pop up(configuration failure). The same logic is used if the configuration file contains wrong information (lets say a wrong host name).

How you solve this problem ?

Regards,
Mihai

Each application mode(server,client and standalone) has it own configuration file.

I have no idea what you are saying here. In my version of B&S, there is only one configuration file allowed and it must be called suncertify.properties

Hi,


In my version of B&S, there is only one configuration file allowed and it must be called suncertify.properties


Yes, similar for me. I don't see anything wrong with having just one file. For example, if you are only running the client part, then you just ignore all the server configuration values in that file (or rather just never end up using them).

Cheers, Jared.

no Mihai.
There is 1 config file which contains both clientside AND serverside information.
That's mandatory, do it differently and you get an automatic failure.

Do NOT start the server or client and just assume that what's in that file is what the assessor wants to use, you MUST give a chance to change the settings. Fail in that and it's another automatic failure.
You MUST also save whatever is entered as connection data (certainly if it's valid at the time), fail that and you have another automatic failure.
If no data is available in the config file, present some defaults (this I believe isn't mandatory, but it's good practice).

Using your scheme you'd get an automatic failure on at least 2 grounds.

Hi, people

and thanx for your interest on this theme

Bob, this is true, I only have one file (suncertify.properties) and only one mechanism to manage/manipulate it. What I try to say with :

Each application mode(server,client and standalone) has it own configuration file.

is that in the client server mode each application part has its own file(one on the server machine and one on the client machine). The file has the same name for both and (maybe) the same content.
For the standalone mode I have only one file(suncertify.properties) - if this file contains server information(host, port) this information are ignored.

Jeroen, I have a configure UI for all modes (server, client, standalone). If the user starts a UI(server, client or stand alone) and is not satisfy by the actual configuration (from the properties file) he can alter it using the configure UI but if a properties file exist it will be loaded&used like current configuration, otherwise I don't see the usage of a persistent configuration.
I try to "draw" the work flow :

1.If the file exist :

start UI -> load suncertify.properties -> use the UI with the actual configuration
start UI -> load suncertify.properties -> change the actual configuration -> use the UI with the changed configuration

2.If there is no configuration file :

start UI -> generate a default properties -> announce the user -> use the UI with the actual configuration
start UI -> generate a default properties -> announce the user -> change the actual configuration -> use the UI with the actual configuration

All the changes are persistent, I omit this (by purpose) to make the work flow pictures more simple.

I hope that this make the whole picture a little bit more clear.
[ May 31, 2006: Message edited by: Mihai Radulescu ]

I am trying to implement this properties file.
I am using the same properties file for both client and server.
But I am stuck on writing to the file.

What is the bes algorithm / API to use to update the file.
I have top consider that If there exists an entry...



And i want to change this to



Can someone please help me?

How do I write to a file with a clients config properties..without removing the server's config properties that are in the file already?

I don't see any requirement in my project that allows for the user to change the value of the port number, once it is written to the suncertify.properties file. In my application, once my user chooses a port number, it gets written to the suncertify.properties file. Even though it is not required, they could get a chance to change the port number to be used only under 3 possible conditions (and only for other reasons):
1. They run the program in a mode, from that same directory, that requires more config info than a previous mode and the new mode also requires the port number.
2. They have changed directories.
3. They have deleted the config file.

One possible algorythm:
For each of your modes (Alone, Server, Client):
I) Determine if the file exists in the current directory.
--A) If it doesn't, then create it and prompt the user for whatever items are needed for that mode. (e.g. "Alone mode" only requires the path and filename to the db).
--B) If it does exist, then read the items into memory and check to see if you have everything you need for that mode.
----1) If you do not have everything you need, prompt the user for the remainder of the items.
----2) If you do have all the items you need, then don't prompt the user, and go onto your normal first screen in your application.

I just used a random access file, because that is what I was comfortable with from the other parts of the project.

CAUTION: Please be aware that the assessor could easily run your program in alone mode first, then run either the server or client from that same directory afterward. We simply do NOT know the order of how s/he will test the different modes of our program. Your app should be prepared to handle the suncertify.properites file being in a variety of states. See previous post on this same thread.
I hope this helps.
[ May 31, 2006: Message edited by: Bob Nedwor ]

Hi, People


I use in my implementation a java.util.Properties - it already provides all the needed features.

Bob , why you use the raf ?

Regards,
Mihai

Bob, in your scenario the user would have to modify the properties file directly in order to change the startup settings for the server.
That's an automatic failure.

Sham. Quite simple:

at application start, read the entire file and use the stuff you need.
when saving the properties, reread the file, update the fields needed, and save the entire file.

The Properties class has mechanisms to do all that built in.

Guys,

Thanks a million. I never knew about the properties api.
I was messing around with FileInputStreams & BufferedOutputStreams for the last couple of days. And as u can imagine, my code was getting very messy and i was starting to realise that this was not possible with the mechanisms i was using.

Had it all done in 15 mins after discovering java.util.properties.
Thanks Jeroen, Mihai & Bob.

Jeroen:

Bob, in your scenario the user would have to modify the properties file directly in order to change the startup settings for the server.
That's an automatic failure.

I disagree. You might have a different version of the B&S project than I do. There is no "must" in my instructions.html that requires the user to have the ability to change the settings after they are provided via the GUI and written to the suncertify.properties file.

Can you quote the "must" from your instructions.html that leads you to believe that this is the case?
Thanks.

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

You don't allow such configuration after the first run of the program, which as I interpret the above is a violation of a strict requirement.
Your users would have to edit the properties file in order to change the application startup behaviour...

Yes, I have that statement too. My configuration will be persistent between runs of the application. But the ability to enter or change that configuration does NOT have to be persistent, at least not by any requirement/must that I see.

Maybe I have drawn an incorrect distinction between the configuration and the mechanism to allow the user to enter the configuration, but I don't think so.

Good for you if you went the extra step to provide both.

how will you allow users to change the configuration once it's initially set?
If you don't that violates the requirements as I see it, not worth the risk...

how will you allow users to change the configuration once it's initially set?

We are not required to provide this. Once the configuation is set, it remains persistent through subsequent runs of the application.

As long as I provide the user a GUI to enter the configuration data, and the application can read that file and use that data each time it is run, I have met the requirement.

If the user changes his/her mind after the data has been written to the suncertify.properties file, then too bad, because we are not required to handle this.

Only the data in the file itself has to be persistent, not the users capacity to enter it. Sorry if I see the two as being separate. I think you may be seeing
a) the configuration
and
b) the GUI used to enter the configuration
as being wrapped together somehow, as one one item that the requirement is targeting. But I don't see it this way.

Maybe Andrew can shed some light on this?

Hi,

Originally posted by Bob Nedwor:

We are not required to provide this. Once the configuation is set, it remains persistent through subsequent runs of the application.

I am actually allowing people to change configuration settings after an initial setup and to persist that change. I interpret "All configuration" to mean initial and subsequent attempts to configure the application. It seems that you have interpreted it to mean "inital time only".

I guess that is fine, but you may need to explain that thinking in your choices document, or the user manual.

In a real world situation I think your approach is very limiting and would have many problems when delivered for clients -- imagine having to reinstall the whole application again if a client wanted to change a connection parameter through the GUI ...

Cheers, Jared.

Thanks, Jared.

I can see how yours would also be a valid interpretation of the "must."

In a real world situation I think your approach is very limiting and would have many problems when delivered for clients...

In a real world situation, I would be using Oracle 10g, not a flat file on disk..

in a realworld situation you run what the client has available or is willing to pay for...

Hi All

Just thought I would add my experience on this issue. I recieved an automatic failure on my project which automatically connected using previous configuration settings. My package on first use would display an error message about a connection problem. The user could then use the configuration functionality to set the correct parameters.

My new approach is to display a connection dialog on startup displaying the property values stored. The user chooses connect, the property is stored and the application connects. I hope to resubmit soon.

Just watch for this problem!

Bob, in your scenario the user would have to modify the properties file directly in order to change the startup settings for the server.
That's an automatic failure.

Jeroen,
It looks like you have just been overruled by one of the exam assessors , because I passed!

The "All" in "All configuration must.." probably refers to all of the various items (path/filename to db, port, ipaddress, etc).

I repeat: You DO NOT have to provide the ability for the user to change the config settings once they have been set!!

This is NOT a must, at least not in my version of the B&S project. I certainly did not provide this and I passed!!
[ June 11, 2006: Message edited by: Bob Nedwor ]

Congrats, but I think I'll rather be safe than sorry

Originally posted by Jeroen T Wenting:
Do NOT start the server or client and just assume that what's in that file is what the assessor wants to use, you MUST give a chance to change the settings. Fail in that and it's another automatic failure.

Sorry for responding on this old subject. I have searched for something newer, but I am having a hard time finding this in newer posts.

I have looked at the assignment very well. I can't find anything that requires that a user can change settings before connecting.
Question for anyone reading this: Do you have a quote from your assignment that says you can not use the persistent settings without first asking the user??

I just have a menu option to change settings. If connecting fails or the settings are not complete (in that case no connection is attempted) then a message pops up with the reason and "Please check your connection settings: File -> Configure URLyBird connection."
What is wrong with that?

Henri.

What I have done in my case is:

1. The application tries to connect on the current settings provided by the suncertify.properties file.

2. If the application connects - no settings dialog is shown.

3. If some exception is generated, the settings dialog is shown so that the user enters correct settings (such as a correct server IP address).

4. If the application connects as described in (2) and the user did not really want to connect to this server, he can access the settings through the GUI and connect to another server using different settings.

Futher to Jeroen T Wenting's post- I did not submit the suncertify.properties file ( i don't actually think it has to be submitted). The file is created automatically if it is not found. Then the settings dialog is automatically shown upon startup (as with empty settings the application can't connect). Then once correct settings are entered, the asessor can use the application how much he likes without entering the settings again, provided that the server is still online on the same IP and on the same port.
[ July 08, 2007: Message edited by: chris bajada ]

Hi guys,

This old post, they bring back such memories .

Do you have a quote from your assignment that says you can not use the persistent settings without first asking the user??

In my specification I have something like :

In either case, the program must allow the user to specify the location of the database, and it must also accept an indication that a local database is to be used, in which case, the networking must be bypassed entirely.

and I interpret this like : the user must specify, always, the operation mode. With other no auto-loading - the first UI that the user sees is the configuration dialog. In my implementation I provide three a remote an local and a compound dialog (it provides the both configuration features and allows the user to toggle between them).
If you like this auto-load for the configuration you can provide a auto load check box (hided in menu somewhere).

Regards,
M

To Mihai Radulescu:

The assignment says:

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 if I understand you correctly, you can start your programm in client mode (no argument) and then in a configuration dialog override the initial program mode, switching to stand-alone mode without restarting the JVM ?? So the program operates in stand-alone mode even though it was started in client mode

That does not sound right to me.

Hi Henri,

It is like this the command line argument sets only the start mode, the user can change this mode (from local to remote).
This was my way to interpret the specifications.

Regards,
M