• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

about properties.txt problem

 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
Ranch Hand
Posts: 181
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 181
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 210
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 210
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 181
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 210
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 181
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
     
    author and jackaroo
    Posts: 12200
    280
    Mac IntelliJ IDE Firefox Browser Oracle C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
     
    reply
      Bookmark Topic Watch Topic
    • New Topic