Meaningless Drivel is fun!*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX:packaging suncertify.properties 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 "NX:packaging suncertify.properties" Watch "NX:packaging suncertify.properties" New topic
Author

NX:packaging suncertify.properties

jerome bosman
Greenhorn

Joined: May 25, 2003
Posts: 1
to be part of the runme.jar ?
but to be modified through GUI ?
so to be part of the .jar with a first extract
on the first run ?
instructions said a file in the working directory but the "Packaging of Submissions" doesn't mention it.
Freedom of speech.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Jerome,
Welcome to JavaRanch.
I dont think you need the suncertify.properties file in any of the jar files.
On startup, you can check whether suncertify.properties exists or not, and if it does exist then you read it, if it doesnt exist you can either provide hard coded default values (I have hard coded default values of server = "localhost" and port = java.rmi.registry.Registry.REGISTRY_PORT) which the user can overwrite, or you can just leave everything blank - force the user to enter values.
Once the user has confirmed their options, you can check for the existance of the suncertify.properties file, and if it doesnt exist then you can create it.
Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Billy Tsai
Ranch Hand

Joined: May 23, 2003
Posts: 1297
Hi
I have A GUI to enter the server port and start the server so do I need to store the server port number is suncertify.properties as well?
or is that file only for clients to store their information? because in the instruction 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.
so if I dont store the server's GUI configure(port) in that suncertify.properties which is the same file used by the client, does it mean I will fail automatically?
please help ,thanks


BEA 8.1 Certified Administrator, IBM Certified Solution Developer For XML 1.1 and Related Technologies, SCJP, SCWCD, SCBCD, SCDJWS, SCJD, SCEA,
Oracle Certified Master Java EE 5 Enterprise Architect
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Billy
Your instructions start with "Your programs" where programs is plural - so all programs you write would need to store their configuration data in suncertify.properties.
Regards, Andrew
Billy Tsai
Ranch Hand

Joined: May 23, 2003
Posts: 1297
so the server program and the client(network mode) program must store their configurations into the same suncertify.properties file is that right?
but I use the following codes
FileWriter file=new FileWriter("suncertify.properties");
BufferedWriter output=new BufferedWriter(file); String s=addressField.getText();
String s1=serverPortField.getText();
output.write("connect.port=");
output.write(s1, 0, s1.length());
output.newLine();
output.write("connect.IP=");
output.write(s, 0, s.length());
output.newLine();
output.close();
and similar codes for the server
so everytime the client receives a new setting the property file will be overwritten causing the server configuration to be erased or the server receives the port and causing the client configuration to be erased, so there is no way to be persistent between runs of the program, since both program use the same file, any idea how to work around that?
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

Billy, there is a class called Properties. You are reinventing the wheel and will be marked down for it. Check out the Properties class.
Implementing one is very easy. Use the no arg constructor. Create a FileInputStream and use it to read the properties file, or create a FileOutputStream to write to the properties file.
use getProperty and setProperty. You can read all about it in the API documentation.
Use a different file for client and server. They should not use the same file, since it is possible that the server is running on a completely different machine.
Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Billy Tsai
Ranch Hand

Joined: May 23, 2003
Posts: 1297
But in the instruction it says Such configuration information must be stored in a file called suncertify.properties
so that means for client and server programs they must use that file, but the problem is if the client output its configuration then the server configuration will be erased and vice versa...
..................
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Billy
Mark's comments about using the Properties class still applies - it would be a really bad idea to make your own class that does the same work as the Properties class.
Getting around the fact that both client and server use the same properties might require some more clever coding from you.
As a bare minimum, you should be reading in the properties file (both client and server properties). You then allow the user to make changes to the properties for the application that they are currently running. You then write back all the properties (both client and server properties).
There is still a potential problem with the two applications starting at the same time:
  • server starts, reads properties
  • client starts, reads properties
  • server modifies properties
  • client modifies properties


  • There are two things you might want to look at here: looking at the modification time of the properties file before you start to write, and creating an exclusive lock to ensure that only one application can do an update on the file (where I term an update as reading in the (modified) file to get any changes made by other apps and writing out the modified data). I have not furnished any specifics yet - I want you to have a think about it for yourself first.
    Regards, Andrew
    Billy Tsai
    Ranch Hand

    Joined: May 23, 2003
    Posts: 1297
    wouldnt locking the suncertify.property file be out of the scope of the assignment and as an addition feature, I have used Property to read all the properties then update the necessary ones for a particular program then write them all back to the file, but locking the file and doing what u described in the last paragraph is way out of my league, I have no idea how to do it totally and isn't fileLock platform depended so its against the spirit of the SCJD exam
    Billy Tsai
    Ranch Hand

    Joined: May 23, 2003
    Posts: 1297
    I suppose I can using the locking mechanism I wrote for lock and unlock method in Data.java but I just want to know is locking the suncertify.properties file feature necessary? is it a feature that deviate from the (NX)Contract assignment? would I get marked down for doing it or not doing it,
    anyone passed without locking the suncertify.property file?
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11404
        
      81

    Hi Billy,
    wouldnt locking the suncertify.property file be out of the scope of the assignment

    That is something you have to decide. If you decide that it is out of scope, then you have to decide whether you are going to document the potential issue I mentioned above or not.
    I have used Property to read all the properties then update the necessary ones for a particular program then write them all back to the file

    Excellent - now you have to make your own mind up as to whether catering for the issue I mentioned is out of scope or not.

    Andrew: creating an exclusive lock to ensure that only one application can do an update on the file
    Billy: isn't fileLock platform depended so its against the spirit of the SCJD exam

    You are correct that file locking is platform dependant. But I didn't suggest file locking . To give one example of how you could handle exclusive locking, perhaps you could use an additional file's existance to act as an update lock. From the API documentation for File.createNewFile():
    Atomically creates a new, empty file named by this abstract pathname if and only if a file with this name does not yet exist. The check for the existence of the file and the creation of the file if it does not exist are a single operation that is atomic with respect to all other filesystem activities that might affect the file. This method, in combination with the deleteOnExit() method, can therefore serve as the basis for a simple but reliable cooperative file-locking protocol.

    All of which is just academic if you decide this is out of scope
    Regards, Andrew
    Mark Spritzler
    ranger
    Sheriff

    Joined: Feb 05, 2001
    Posts: 17249
        
        6

    So if the client is running on one machine and it is using the suncertify.properties file and the server is on a completely different machine, would they have two seperate properties file, one on the server machine one on the client.
    That is what I mean by you should have two seperate files. How can you maintain one file when there are more than one machines accessing it. And then you have the scenario where you have 100 clients all running the app, and they are all on seperate machines, and each want to run a different configuration.
    You can't do that logically with one properties file. You have to have each client have their own properties file for their own configuration. This file is included with the client.jar. And the server has its own properties file that is in the server.jar.
    Mark
    Ta Ri Ki Sun
    Ranch Hand

    Joined: Mar 26, 2002
    Posts: 442
    Originally posted by Mark Spritzler:

    You can't do that logically with one properties file. You have to have each client have their own properties file for their own configuration. This file is included with the client.jar. And the server has its own properties file that is in the server.jar.
    Mark

    We dont really have that luxury with the new exam Mark,
    suncertify.properties which must be located in the current working directory.

    also
    When you submit your assignment, each part (client and server) must be executable using a command of this exact form:
    java -jar <path_and_filename> [<mode>]

    given those 2 factors the jar we submit will either have this file in its root, and also at that level we must have runme.jar, so to execute the command is java -jar runme.jar [<mode>], or the properties file could be copied to any directory the assessor likes to execute use the following as an example java -jar /usr/share/assignment/runme.jar [<mode>] , but then the assessor would also have to copy the database if required to that share directory, because that has the same restriction.
    so while its possible and might make sense for some to have a client.jar and server.jar inside the runme.jar we cant package suncertify.properties in each of them.
    Mark Spritzler
    ranger
    Sheriff

    Joined: Feb 05, 2001
    Posts: 17249
        
        6

    Those two quotes you use say absolutely nothing about the server and client configuration should be in one and only one properties file.
    What the quotes says still completely supports my suggestion.
    When you submit your assignment, each part (client and server) must be executable using a command of this exact form:
    java -jar <path_and_filename> [<mode>]

    So that is the java command, absolutely nothing to do with property files.
    suncertify.properties which must be located in the current working directory.

    Yes, what this means is that If I am client A, I run my client from a directory, my personal properties file should be in that same location. Now server A on a totally different machine has its own properties file, which is located on the directory it runs the server from.
    Two seperate properties file, still meeting those two requirements.
    I can't think of any other better way to explain it. Jim any help?
    Mark
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11404
        
      81

    Hi Mark
    Nice solution, but it doesnt meet the requirements (didn't you psychically pick up on the ones not mentioned? )
    Note: These are only a subset of the requirements:

    When you submit your assignment, each part (client and server) must be executable using a command of this exact form:

    Your programs must not require use of command line arguments other than the single mode flag, which must be supported. 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.
    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.
    All elements of your submission must be packaged in a single JAR file. The JAR file must have the following layout and contents in its root:
  • The executable JAR containing the programs. This must be called runme.jar.

  • So, if there can only be one runme.jar which contains all the code for both client and server, and both client and server must store their configuration in suncertify.properties, then you would have to allow for the case where both client and server are started from the same directory.
    Regards, Andrew
    George Fung
    Ranch Hand

    Joined: Jun 12, 2003
    Posts: 98
    Hi Mark,
    As client and server has separate properties file. Each client has its own properties file. It's not possible that more than one machines access a file. SO, we don't care file lock or any kind of locking on file and data in configuration files. Do you agree?
    George
    Originally posted by Mark Spritzler:

    That is what I mean by you should have two seperate files. How can you maintain one file when there are more than one machines accessing it. And then you have the scenario where you have 100 clients all running the app, and they are all on seperate machines, and each want to run a different configuration.

    Mark[/QB]


    SCJP, SCJD, SCWCD, SCBCD, SCEA, SCJP6
    To be obtained: SCEA 5
    George Fung
    Ranch Hand

    Joined: Jun 12, 2003
    Posts: 98
    Hi all,
    Actually, I don't understand how to package for submission. Can anyone tell me?
    There is one and only one jar file for submission. That's runme.jar
    In runme.jar, there are many directories: code, docs, server and client.
    For server dir, there are 2 files.
    server.jar (server side runnable program) and server's suncertify.properties
    For client dir, there are 2 files.
    client.jar (client side runnable program) and client's suncertify.properties
    The examiner will extract it and run it by java -jar client/client.jar (client side) &
    java - jar server/server.jar (Server side).
    Am I correct? Then we can separate the configuration into 2 different files. It seems more logical.
    George
    Originally posted by Andrew Monkhouse:
    Hi Mark
    Nice solution, but it doesnt meet the requirements (didn't you psychically pick up on the ones not mentioned? )

    So, if there can only be one runme.jar which contains all the code for both client and server, and both client and server must store their configuration in suncertify.properties, then you would have to allow for the case where both client and server are started from the same directory.
    Regards, Andrew
    Billy Tsai
    Ranch Hand

    Joined: May 23, 2003
    Posts: 1297
    No you are not correct , you are wrong.
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11404
        
      81

    Hi George,
    If you are doing the older Airline assignment then most of this topic does not apply to you, and you can package your assignment the way you suggested. You should see the section of your instructions marked "Deliverables" for more information.
    However, if you are doing the new assignment (Writing a Contractors application or a Hotel application), then you should check for instructions similar to the ones I listed above, including the first bullet point I took from the section "Packaging of Submissions".
    The way I read the instructions, you will have one jar file for the submission. The name of it is not specified in the instructions, but is usually specified when you are about to upload the assignment. For the sake of clarity, I will call this jar file scja.jar.
    In the root directory of scja.jar, you will have the "runme.jar" file which must be executable. It will not be unpacked by the examiner, and it must have both client and server code in it.
    There are more files and directories that will go into scja.jar, but they are not applicable to this topic, so I wont list them here.
    Regards, Andrew
    Ta Ri Ki Sun
    Ranch Hand

    Joined: Mar 26, 2002
    Posts: 442
    @ Andrew : Thanks for pointing out what I thought was given, my bad Mark, sorry.
    @ George : Your one and only jar for submission can temporarily be named extractme.jar or whatever pleases you, as I understand you'll be told when you submit what to rename your file to, includes your SP#.
    George Fung
    Ranch Hand

    Joined: Jun 12, 2003
    Posts: 98
    Hi Andrew,
    my assingemnt is new one (contrator). Could you suggest the structure of the scja.jar?
    In my requirement "When you submit your assignment, each part (client & server) must be executable using a command of this exact form:
    java - jar <path_and_filename> [<mode]>
    So, is runme.jar for server or client side? Also, server and client side has different suncertify.properties. right?
    Thanks,
    George

    Originally posted by Andrew Monkhouse:
    Hi George,
    If you are doing the older Airline assignment then most of this topic does not apply to you, and you can package your assignment the way you suggested. You should see the section of your instructions marked "Deliverables" for more information.
    However, if you are doing the new assignment (Writing a Contractors application or a Hotel application), then you should check for instructions similar to the ones I listed above, including the first bullet point I took from the section "Packaging of Submissions".
    The way I read the instructions, you will have one jar file for the submission. The name of it is not specified in the instructions, but is usually specified when you are about to upload the assignment. For the sake of clarity, I will call this jar file scja.jar.
    In the root directory of scja.jar, you will have the "runme.jar" file which must be executable. It will not be unpacked by the examiner, and it must have both client and server code in it.
    There are more files and directories that will go into scja.jar, but they are not applicable to this topic, so I wont list them here.
    Regards, Andrew
    Ta Ri Ki Sun
    Ranch Hand

    Joined: Mar 26, 2002
    Posts: 442
    Originally posted by George Fung:
    Hi Andrew,
    my assingemnt is new one (contrator). Could you suggest the structure of the scja.jar?
    In my requirement "When you submit your assignment, each part (client & server) must be executable using a command of this exact form:
    java - jar <path_and_filename> [<mode]>
    So, is runme.jar for server or client side? Also, server and client side has different suncertify.properties. right?
    Thanks,
    George


    runme.jar is for both client and server, that optional mode argument determines what runs.
    so "java-jar runme.jar" will run your GUI but attempt a network connection, "java -jar runme.jar alone" will run in standalone mode, and "java -jar runme.jar server" will run your server.
    As Andrew suggested, please check your "Deliverables" section for details regarding packaging.
    as for how many props files you have, there are currently more ideas than one regarding this, I'll stick to having one file in the root of my submission jar until convinced otherwise.
    The file can be moved but then wherever its moved to must also be in System.getProperty("user.dir"), meaning thats where the program is started from.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: NX:packaging suncertify.properties
     
    Similar Threads
    Good one..... ( System.out.println() )
    How to appear for Part II
    Regarding Jar Utility
    SCEA
    JSP Help!!