I would like to make sure the rule in the instruction about deliverables. While executing the program, the following command is allowed: java -jar <path_and_filename> [<mode>] it says: Your programs must not require use of command line property specifications. 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. We must use either "server","alone",empty to indicate the mode running. What should we put in suncertify.properties file, and what it really means "All configuration must be done via a GUI, and must be persistent between runs of the program", many thanks in advance!
Hi, You have to put in the suncertify.properties the look and feel class, server port number, host name, database name with absolute path. Look... If the application is running in the standalone mode, you must to save the database name with absolute path for standalone mode. If the server is running, you must save the port number and the database name with absolute path for the server. To the networking client you must save the host name and the port number. And to both, network client and standalone mode, if the usar change the look and feel you must to save it. You need to load this properties and set them up. bye, Wilder SCPJ SCWCD P.S.: sorry, I'm brazilian and my english isn't too good.
Wilder is absolutely correct, except "look and feel class" This is only because the requirements does not require you to make the GUI have the ability to change the look and feel. And if you application does not supply this ability, then you don't need to save this in the properties file. If you do include this "enhancement", then I agree that you should save this in the properties file. p.s. you will not get any extra points because you added the ability to have the user change the look and feel. But, it is possible that you could lose points. Mark
Note that many "enhancements" are easy enough to code, but then later on, it's just one more thing to document. :roll: I've been pulling out several unnecessary features for precisely this reason.
I am a little hazy on the responses to this thread, if we are supposed to set all of these properties via the gui than are supposed to prompt the user with a file chooser for them to locate the database file on their harddrive?? I can't think of any other way to properly enter the absolute path of the database file, has anyone done it this way (with a file chooser)??? And does anyone know where the suncertify.properties file should be located within your project, b/c the instructions state that it: must be stored in a file called suncertify.properties which must be located in the current working directory. Does anyone know what sun means by current working directory?? Where in the jar file are they refering to, the gui package? the location of the classes taht will be accessing this properties file? If anyone has any ideas that would be great. Thanks! Dave
Originally posted by Dave Knipp: I am a little hazy on the responses to this thread, if we are supposed to set all of these properties via the gui than are supposed to prompt the user with a file chooser for them to locate the database file on their harddrive?? I can't think of any other way to properly enter the absolute path of the database file, has anyone done it this way (with a file chooser)??? And does anyone know where the suncertify.properties file should be located within your project, b/c the instructions state that it: must be stored in a file called suncertify.properties which must be located in the current working directory. Does anyone know what sun means by current working directory?? Where in the jar file are they refering to, the gui package? the location of the classes taht will be accessing this properties file? If anyone has any ideas that would be great. Thanks! Dave
I was going to just quote certain parts of your post, but realized that there are many Questiosn there. 1. With FileChoser you will return a File object, in the File object there are methods to get the absolute file path. 2. Current working directory is the directory that you are in when you start/run your program. meaning if I put my runme.jar file in c:\mydir\rdrr then c:\mydir\rdrr is the working directory, so that is where the suncertify.properties file should reside. "Where in the jar file are they refering to, the gui package?" I am confused on this question. I would think you might be referring to the runme.jar file that is mentioned in your instructions.html document. Hope that helps Mark
ahh, cool. Yah i figured that i would just get the absolute path off of the file chooser, I was more asking whether or not this is how people had done it in the past. As far as the suncertify.properties file goes the assignment accessor would actually have to extract the suncertify.properties file from the jar and put it in the directory where the runme.jar is located, correct? This sounds feasible now that i think about it, since we are going to have to bundle many different things within the main jar. Thanks a ton for your answers! Dave
HI all, I have read this and am a little confused by the idea of; when in network mode, writing the absolute path of the DB within the properties. If you are using it in network mode the client will not be able to see the location of the DB on the server. The client commutates with the server over sockets; why would the client need to know where the DB is located on the server. The client will only need to know the IP address and port number. I agree that the server app needs to know where the DB is located on the server. How will the server read the properties if it is on the client? If I move the properties file to the server then how would the client know the IP address and port number of the server? So we need two properties file in network mode. Or have I just missed the point? Thanks Chris
2. Current working directory is the directory that you are in when you start/run your program.
Agreed.
meaning if I put my runme.jar file in c:\mydir\rdrr then c:\mydir\rdrr is the working directory, so that is where the suncertify.properties file should reside.
Agreed if you started the JVM from that same directory. But if you started it as follow : c:\> java -jar mydir\rdrr\runme.jar the current directory will be c:\ Anyway, the current directory if the one returned by System.getProperty("user.dir"). Best, Phil.
Hello, I am not saving any property file, instead I am creating one in user's current directory if it's not present and if it's there then I am just using it for all (client & server). Is it ok?.
I have read this and am a little confused by the idea of; when in network mode, writing the absolute path of the DB within the properties.
I think the instructions do not require you to specify an absolute path to the data file. What they require is the location of the data. In local mode, the location could be the absolute path to the data file. In remote mode, the location could be an IP address and port where the client can find the network server. Make sense? But that raises another issue - you may need a GUI on your server so that the person starting server can also specify the location of the data file. Regards, Andrew
Originally posted by Manoj Dixit: I am not saving any property file, instead I am creating one in user's current directory if it's not present and if it's there then I am just using it for all (client & server). Is it ok?.
I am confused. You say you are not saving the property file. Then you say you are creating a property file if it doesnt exist. Do you mean that you are not supplying a property file inside your submission? That seems reasonable. And since you are creating one if it does not exist (thereby saving current choices) you are meeting the requirement that choices persist. Regards, Andrew
Hi Andrew, Thanks for the advice. What you have said makes sense, however:
But that raises another issue - you may need a GUI on your server so that the person starting server can also specify the location of the data file.
Is this the approch most people are taking? The specs say:
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.
So is this saying that in network mode we need to GUI? one for the client and another for the server. On the sever there is also a suncertify.properties? Thanks Chris. [ October 18, 2003: Message edited by: Chris Harris ]
I think that's what most of us are doing, yes. There are some properties that the server admin needs to be able to control, such as port number and DB file path. (Or you can let different clients request different files, but down that road lies madness, as well as serious security risks.) In order for theses choices to be persistent, they should be held in a suncertify.properties fil, and the specs require that they be editable via GUI. Even though there's little else you need a GUI for on the server. (Some of us have a "Stop Server" button; little else.)
Andrew But that raises another issue - you may need a GUI on your server so that the person starting server can also specify the location of the data file. Chris Is this the approch most people are taking?
I believe a large number of people are doing this. The whole idea of using a GUI on the server goes against my general principals, but in this case it seems to be the best way to meet the requirements. Having a GUI for the server has a nice side effect - you can give the examiner a nice easy way to shut down the server.
On the sever there is also a suncertify.properties?
I think there has to be. Now - what do you do if the client starts in the same working directory as the server? Or the server starts in the same working directory where the client previously started? Do you keep the properties for client and server separate within the one file? (I think you have to) Do you try to do file level (in a platform independant manner!) locking on the suncertify.properties file against the unlikely case that two applications try to start simultaneously? Or do you just acknowledge in your design documentation that this is an issue? Regards, Andrew [ October 18, 2003: Message edited by: Andrew Monkhouse ]
what do you do if the client starts in the same working directory as the server? Or the server starts in the same working directory where the client previously started?
Isn't the behavior just the same as ordinary network mode? Is there any trick in it?
Do you keep the properties for client and server separate within the one file? (I think you have to)
What do you mean by this, I suppose only 2 information is need by customer, and they should be consistent. 1. server host name(or ip) 2. server port number is this correct?
quote: what do you do if the client starts in the same working directory as the server? Or the server starts in the same working directory where the client previously started? Isn't the behavior just the same as ordinary network mode? Is there any trick in it?
It's quite different : if both server and client are started on the same machine and from the same directory, they'll access the same properties file from two separate JVM instances.
quote: Do you keep the properties for client and server separate within the one file? (I think you have to)
What do you mean by this, I suppose only 2 information is need by customer, and they should be consistent. 1. server host name(or ip) 2. server port number is this correct?
It seems to be. But it could happen that two properties with a same name have a different meaning (or may have a different value) in different applications. Examples : dbFileName could have a different value in stand-alone mode. "mySpecialProperty" could have a different meaning in server and in client. A given client could connect to a different server for debuging purposes. And so on. So I think that prefixing properties names (with "server.", "client.", "alone.", ...) could be good practice.
Andrew: Do you try to do file level (in a platform independant manner!) locking on the suncertify.properties file against the unlikely case that two applications try to start simultaneously? Or do you just acknowledge in your design documentation that this is an issue?
A long time ago, Andrew suggested to implement such a locking by creating some temporary file acting as a semaphore. Unfortunately, here is what is written in File.createNewFile() doc :
Note: this method should not be used for file-locking, as the resulting protocol cannot be made to work reliably. The FileLock facility should be used instead.
And if you read the javadoc FileLock "Platform dependencies" section, you'll conclude that FileLock is all but platform independant. In a previous thread on the subject, someone noticed here that as you have only one keyboard, it's impossible to save properties from the client and from the server at the same time. I think he's right, as far as you take care of loading the properties from the file just before (and in the same method) setting and saving them, like here :
Hi, I'm sorry, but I made a mistake when I said that my assignment asked me to change the look and feel. I did read again all my assignment. I found that: ----------------------------- 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. ----------------------------- I'm so sorry. :roll: Bests, Wilder SCPJ SCWCD
Is the following network administration GUI summary ok? 1. For Server mode, a GUI which prompts user enter server name(or IP, which should be network reachable), port number(1000~9999), a button which allows user specfingy the database file, a Start server button, and a Stop server button. 2. For Client mode, a GUI which prompts user enter server name(since he is aware of which server he is accessing), port number(he knows this in advance too), a Start Client button. Once the user clicks on the Start button and it successfully builds up connection, it shows up the main GUI; otherwise an warning is shown with Exception message. 3. For Standalone mode, a GUI which allows user specifying the database file location, and a Start button which takes him to main GUI. For the above information which involves user interaction should be save in property file. Please comment...
Post by:autobot
If you live in a cold climate and on the grid, incandescent light can use less energy than LED. Tiny ad:
a bit of art, as a gift, the permaculture playing cards
![[Logo]](/templates/default/mobile/images/mobile-moose.gif)
