aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes about properties.txt problem Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "about properties.txt problem" Watch "about properties.txt problem" New topic
Author

about properties.txt problem

Vince Cheung
Greenhorn

Joined: Dec 06, 2004
Posts: 16

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.

1. My first question is can I get configuration from properties.txt and don't let client to config it via GUI? I use sockets so I must use "serverPort" which is the port number of server to create socket at client side. Server side must config it into properties.txt. If I config it via client GUI, it will has a big chance to be different from configging by server.

2. My second question is which directory is the current working directory?
my tree is:
ScjdSubmission__db-1x3.db
________________vertion.txt
________________doc__________choices.txt
_____________________________userguide.txt
_____________________________instructions.html
_____________________________javadoc____________.....
________________code_________suncertify_________db
________________________________________________client
________________________________________________server
________________________________________________common

Thanks for giving me help

[ December 15, 2004: Message edited by: Vince Cheung ]
[ December 15, 2004: Message edited by: Vince Cheung ]
Daniel Simpson
Ranch Hand

Joined: Sep 02, 2004
Posts: 181
I have many similar questions as well. Obviously, if you do not follow those explicit must's they will fail you. I think GUI configuration in local should allow the client to search their computer for the DB file. Since the server must be run before the client/gui in networked, configuration could definitely be done through running the server. Also, persisting configuration needs to be done through the Properties class. Look under the java.util package for Properties. They are quite easy to use. Hope this helps.


SCJP 1.4<br />SCJD 1.4
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Vince Cheung:
1. My first question is can I get configuration from properties.txt and don't let client to config it via GUI? I use sockets so I must use "serverPort" which is the port number of server to create socket at client side. Server side must config it into properties.txt. If I config it via client GUI, it will has a big chance to be different from configging by server.

2. My second question is which directory is the current working directory?
my tree is:


1) The client or server should be able to reconfigure the "sunceritify.properties" file at any time. This shouldn't affect other programs that are already running, but it will modify their behaviour when they are restarted. It's quite possible to run more than one server and switch the client to the other server while its running.

2) the current directory is the directory which you started the program in, its returned by System.getProperty("user.dir"). If you just use new File("suncertify.properties") that's the one you get. It's possible to start 2 clients in seperate directories accessing different servers, I do it while testing.
Mike He
Greenhorn

Joined: Feb 24, 2003
Posts: 11
1. My first question is can I get configuration from properties.txt and don't let client to config it via GUI? I use sockets so I must use "serverPort" which is the port number of server to create socket at client side. Server side must config it into properties.txt. If I config it via client GUI, it will has a big chance to be different from configging by server.

As my opinion, your configuration must be done via GUI means that whatever you do should be via a GUI,including establishment and modification.

2. My second question is which directory is the current working directory?

Current working directory is just where your runme.jar is.


Mike<br />SCJP SCJD
David Abramowicz
Ranch Hand

Joined: Dec 10, 2004
Posts: 56
Hang on... Does the server really need a GUI?

In my solution any editing of the properties file is performed through the client GUI.

In networked mode, I have recommended the users that during initial deployment they start their client GUI first and configure properties appropriately. Then start the server... Once this is done the client then has a "connect" button that is used to establish the connection.

In stand-alone mode, the "connect" button is greyed out obviously, which means that directly upon startup the defined data file is loaded. This could obviously cause problems if the data file property is not set appropriately. In this case the user is recommended to edit the config file through the GUI and then restart the application...

Does this approach violate any MUSTs?

Thanks /Dave
Daniel Simpson
Ranch Hand

Joined: Sep 02, 2004
Posts: 181
Originally posted by David Abramowicz:
In this case the user is recommended to edit the config file through the GUI and then restart the application...

Does this approach violate any MUSTs?

Thanks /Dave


I don't believe it does, but I would question your design for this. It seems a bit redundant to run the client gui, configure, shut it down, run the server, run the client again. Personally, if I was a user, I wouldn't like the idea of having to run something, shut it down, and rerun it a minute later. I think it may be a better design to run the server and configure through that, and run the client. Cuts down on the steps in the process. Just my take on it. Feel free to tear it apart.
David Abramowicz
Ranch Hand

Joined: Dec 10, 2004
Posts: 56
I definetly see your point... However, say I update my user manual to this:

If you want to administer the server, do so by using the client in networked mode. After the server has been configured start any servers, clients or standalone applications.

I think I could live with that as a user and an administrator of the service. I mean it's not as if the data file location changes every fifteen minutes...

I'm not trying to get out of writing extra code, promise I just don't see much point with having a GUI for the server... What else do you stick in there, maybe it's something I've missed.

Thanks /Dave
Vince Cheung
Greenhorn

Joined: Dec 06, 2004
Posts: 16
Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory.

I have a doubt which is "a file called suncertify.properties". What's the meaning of "suncertify"? Is "suncertify" a directory or others?
But Mike says
Current working directory is just where your runme.jar is.

I can't understand.
Matt Sheehan.
Ranch Hand

Joined: Oct 08, 2004
Posts: 63
Originally posted by Vince Cheung:

I have a doubt which is "a file called suncertify.properties". What's the meaning of "suncertify"? Is "suncertify" a directory or others?

In this case "suncertify" is the filename and "properties" is the file extension.
Originally posted by Vince Cheung:

But Mike says "Current working directory is just where your runme.jar is."
I can't understand.

Peter's answer is the correct one. Whatever directory you are in when you call "java -jar <path/>runme.jar <flag>" is your current working directory.
Jim Janssens
Ranch Hand

Joined: Sep 24, 2004
Posts: 210
Originally posted by Matt Sheehan.:

Peter's answer is the correct one. Whatever directory you are in when you call "java -jar <path/>runme.jar <flag>" is your current working directory.


Ok, so basicly they mean that you put the properties file in the same directory as the jar file ? Which is in this case the root of the assignment...
When someone takes out the jar file and places it somewhere else (lets say c:\temp) they als have to copy the properties file beside it.
Jim Janssens
Ranch Hand

Joined: Sep 24, 2004
Posts: 210
Originally posted by David Abramowicz:
I definetly see your point... However, say I update my user manual to this:

If you want to administer the server, do so by using the client in networked mode. After the server has been configured start any servers, clients or standalone applications.

I think I could live with that as a user and an administrator of the service. I mean it's not as if the data file location changes every fifteen minutes...

I'm not trying to get out of writing extra code, promise I just don't see much point with having a GUI for the server... What else do you stick in there, maybe it's something I've missed.

Thanks /Dave



Well, if you put all the server configuration in the client GUI configuration pane, you are creating a obscure situation. You should doucment that they first configure the 'server - server settings' which are the actually settings (port etc) for the server. then they have to configure the 'client - server settings' which will be the same as the 'server-server settings' because this is the server the client is conneting to. But, you cannot make just one 'server configuration' because what if they want to start multiple servers ... I know, its not a must but it is just not a logical way to do it.

For the server I would create a very simple jframe with a textarea, start/stop button and a File->Configure... jmenu. Agreed, it is some extra programming, but hey, it are like 4 components, some text and some actionlisteners. The configure uses the same properties file as the client gui does, but edits other properties (client properties start with "client.something" server properties with "server.something") . So, what do you print in the textarea ? some usefull debug information, like 'starting server...' binding remote interface <database>...' . Or when the port is allready in use you say 'Server stoped. Port allready in use. please configure another port and restart the server' .

I know its not much. but doing it this way solves the configuration weirdness and I have to admit, a jframe looks nicer then some dark DOS shell...
Daniel Simpson
Ranch Hand

Joined: Sep 02, 2004
Posts: 181
Originally posted by Koen Serneels:



Well, if you put all the server configuration in the client GUI configuration pane, you are creating a obscure situation. You should doucment that they first configure the 'server - server settings' which are the actually settings (port etc) for the server. then they have to configure the 'client - server settings' which will be the same as the 'server-server settings' because this is the server the client is conneting to. But, you cannot make just one 'server configuration' because what if they want to start multiple servers ... I know, its not a must but it is just not a logical way to do it.

For the server I would create a very simple jframe with a textarea, start/stop button and a File->Configure... jmenu. Agreed, it is some extra programming, but hey, it are like 4 components, some text and some actionlisteners. The configure uses the same properties file as the client gui does, but edits other properties (client properties start with "client.something" server properties with "server.something") . So, what do you print in the textarea ? some usefull debug information, like 'starting server...' binding remote interface <database>...' . Or when the port is allready in use you say 'Server stoped. Port allready in use. please configure another port and restart the server' .

I know its not much. but doing it this way solves the configuration weirdness and I have to admit, a jframe looks nicer then some dark DOS shell...

I think multiple servers is definitely past the scope of this assignment. For this assignment, it seems redundant, too, to configure the server using the server, and configure the client connection to the server when launching the client. Remember, when configuring the suncertify.properties file, you can configure it, but you will need to restart your app for the new changes to take place. My approach, a simple server GUI frame that allows you to choose the port and IP address of the server, and it persists it to the suncertify.properties file. Then, the client GUI runs, and reads in the values from the newly persisted properties file. Just an idea.
Matt Sheehan.
Ranch Hand

Joined: Oct 08, 2004
Posts: 63
Originally posted by Koen Serneels:

Ok, so basicly they mean that you put the properties file in the same directory as the jar file ? Which is in this case the root of the assignment...
When someone takes out the jar file and places it somewhere else (lets say c:\temp) they als have to copy the properties file beside it.


Well, if you have a path "dir1/dir2/dir3/", where runme.jar resides in dir3, and you call "java -jar dir2/dir3/runme.jar" from dir1 the CWD is dir1. If you call "java -jar dir3/runme.jar" from dir2 the CWD is dir2.

To quote this website:
When a program runs under the UNIX or the Windows NT operating system there is a directory where the program is started. This directory is not necessarily the directory where the executable code is or where the basic program is. Sloppy saying: this is the directory where the user prompt was when the user typed in the command line starting the program. This is called the current working directory.
David Abramowicz
Ranch Hand

Joined: Dec 10, 2004
Posts: 56
Originally posted by Daniel Simpson:

I think multiple servers is definitely past the scope of this assignment. For this assignment, it seems redundant, too, to configure the server using the server, and configure the client connection to the server when launching the client. Remember, when configuring the suncertify.properties file, you can configure it, but you will need to restart your app for the new changes to take place. My approach, a simple server GUI frame that allows you to choose the port and IP address of the server, and it persists it to the suncertify.properties file. Then, the client GUI runs, and reads in the values from the newly persisted properties file. Just an idea.


I don't think the server port and IP should be set ONLY from the server. What happens if the server and the client are on different hosts?

Also, I can understand why you may want to set port server-side... But IP-address, hm... Can't really see why I would want to do that. Maybe if I have multihomed machine... Ah well, now I'm just pondering over nitty-gritty details.

Anywho, I'll be quiet and implement a little JFrame for the Server... Could as someone said be nice also to have it print some debug info as well as the whole db path thing, despite the fact that is not a MUST

Thanks /Dave
Jim Janssens
Ranch Hand

Joined: Sep 24, 2004
Posts: 210
Originally posted by Matt Sheehan.:
[QB][/QB]


What you are saying is basicly that the cwd is only defined at runtime. When packaging the assignment we cannot possibly know what the cwd is going to be. This comes down to the fact that we must assume that no property file is present and create one first if it isn't.

So when you launch the gui you load the configuration. The configuration system will first check if there is a property file in the cwd. If there is none, it will create an empty one and popup the configuration panel automatically asking to define the configuration parameters. Upon exit this information is saved to the property file in the cwd.

When there was a property file present in the cwd, the application starts silently and the configuration information is visible/changeable when the configuration panel is opened on request from the file menu.

Now, are we going against the rules if we DO supply a pre-configured property file in the root ? The "Packaging of Submissions" part does not say anything about the placement of the property file. But it does not forbit to add additional files...

This way you could fore see both:

- when they run it from the assignment root (then assignment root = cwd) the supplied property file will be read. It will contain the default port and localhost for the server and the default location './' for the database file which is also in the root of the assignment (this is certain cause its a 'must')

- when they run it from another cwd, the property file is created and the configuration panel pops up asking to configure. When the application is restarted from the same cwd the same property file is read.

So the fundamental question is, is the assignment automatically failed when we supply an extra file the root ? (note that the file is not really required, when they delete it it will still work. It is just for convinience when they do start from the assignment root as cwd)
Matt Sheehan.
Ranch Hand

Joined: Oct 08, 2004
Posts: 63
Originally posted by Koen Serneels:

What you are saying is basicly that the cwd is only defined at runtime. When packaging the assignment we cannot possibly know what the cwd is going to be. This comes down to the fact that we must assume that no property file is present and create one first if it isn't.

So when you launch the gui you load the configuration. The configuration system will first check if there is a property file in the cwd. If there is none, it will create an empty one and popup the configuration panel automatically asking to define the configuration parameters. Upon exit this information is saved to the property file in the cwd.

When there was a property file present in the cwd, the application starts silently and the configuration information is visible/changeable when the configuration panel is opened on request from the file menu.

Exactly.
Originally posted by Koen Serneels:

So the fundamental question is, is the assignment automatically failed when we supply an extra file the root ? (note that the file is not really required, when they delete it it will still work. It is just for convinience when they do start from the assignment root as cwd)

I would guess not. In my implementation, though, I just hard-coded default values to these fields.
Daniel Simpson
Ranch Hand

Joined: Sep 02, 2004
Posts: 181
Originally posted by David Abramowicz:


I don't think the server port and IP should be set ONLY from the server. What happens if the server and the client are on different hosts?

Also, I can understand why you may want to set port server-side... But IP-address, hm... Can't really see why I would want to do that. Maybe if I have multihomed machine... Ah well, now I'm just pondering over nitty-gritty details.

Anywho, I'll be quiet and implement a little JFrame for the Server... Could as someone said be nice also to have it print some debug info as well as the whole db path thing, despite the fact that is not a MUST

Thanks /Dave


Now you got me wondering....can someone who has passed the exam please help me with this? Should we assume that the server and client are on the same machine? For instance, say I configure the server when the server launches and it persists the data to the suncertify.properties file. If the server and client were on different machines, how would the client know what ip address and port to connect to? This has me absolutely baffled. Someone who has passed the assignment, your help is greatly appreciated and welcomed! Thanks!
Matt Sheehan.
Ranch Hand

Joined: Oct 08, 2004
Posts: 63
Originally posted by Daniel Simpson:


Now you got me wondering....can someone who has passed the exam please help me with this? Should we assume that the server and client are on the same machine? For instance, say I configure the server when the server launches and it persists the data to the suncertify.properties file. If the server and client were on different machines, how would the client know what ip address and port to connect to? This has me absolutely baffled. Someone who has passed the assignment, your help is greatly appreciated and welcomed! Thanks!


  • Server mode - prompt for local db file location and port number
  • Network client mode - prompt for IP address and port number
  • Standalone client mode - prompt for local db file location

  • The persistence is used so that when you run in one of these modes, your last choices from the SAME mode will be present as default choices. Also it is assumed that the client-user will know the port and ip the server is running on.

    HTH, Matt
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11525
        
    100

    Hi Daniel,

    Should we assume that the server and client are on the same machine?


    You cannot assume that.

    While the reality is that the client and server will probably be on the same machine when being tested, assuming this could lead you to making some major mistakes.

    One of the reasons for client/server architecture is that you can have multiple clients connecting to the one server - this almost always meens multiple distributed clients.

    If the server and client were on different machines, how would the client know what ip address and port to connect to?


    There are some things which any client connecting to any server must know, regardless of whether we are talking this SCJD project or any other client/server system. If they don't know the IP address / port number, then they must as the system administrator for this information. For example, if you are connecting to an email server at work, you must enter the server information into your email client (or have your email client configured for you by the administrators).

    If the assessor chooses to run your server on one machine and your client on another machine, then the assessor will know the IP address and/or port numbers to use.

    You could make it easy for them and provide a default IP address of 127.0.0.1 (or even better 'localhost') when there is no IP address in the preferences file.

    Regards, Andrew


    The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: about properties.txt problem