wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes suncertify. properties -- Network / non-networked mode Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "suncertify. properties -- Network / non-networked mode" Watch "suncertify. properties -- Network / non-networked mode" New topic
Author

suncertify. properties -- Network / non-networked mode

Peter Yunguang Qiu
Ranch Hand

Joined: Nov 22, 2003
Posts: 99
to read / write suncertify.propeties file(load, store), Is it similar to access db file? Is it need to think of networked or non-networked mode? To change(wirte) this file, is it need to be thread safe. Is it possible that 2 client want to set port or host to different values at the same time?
Peter
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Peter,
To change(wirte) this file, is it need to be thread safe. Is it possible that 2 client want to set port or host to different values at the same time?

You don't need to care about it :
  • In a "normal" use of your system, server and client(s) will run on different machines. As your suncertify.properties file will be created/read/written in System.getProperty("user.dir") (the directory where the JVM was started), they all will read/write *different* files.
  • Now even if you start your server and client(s) on the same machine for tests purposes, you have no way to start them *at the same time*, neither you can click on some "Save" button in two applications at the same time.


  • There are two useful things to do though IMO :
  • prefix your property names with "server." and "client." to make sure that server and client property names never collide
  • re-read the file just before you write it (and in the same method), to make sure that you don't clear modifications done in another application (see below)


  • Possible bad read/write sequence :
    server : read
    client : read
    server : save a change
    client : save a change // changes on the server are lost !
    Good sequence :
    server : read
    client : read
    server : read and save a change
    client : read and save a change // changes on the server are kept
    Regards,
    Phil.
    Peter Yunguang Qiu
    Ranch Hand

    Joined: Nov 22, 2003
    Posts: 99
    Hi, Philippe:
    Thank you very much for your help. Now I know I don't need to care about multi-threading for property file.
    I am still not clear about suncertify.properties file:
    1. On the networked mode, create /read /write suncertify.properties file from/to server machine. On the non-networed mode, create/read /write suncertify.properties file from/to client machine. Am I right?
    Do you mean that on the networked mode, there are 2 copies of suncertify.properties files, one is on the server, one is on the client machine? Why two files are needed? Are there any differences between the two?
    2. Is it a must that suncertify.properties file be stored in a specific irectory (sytem.getProperty("user.dir") ) ? Can it be stored in other directory by using the following code:

    3. I just stored the following items in my suncertify.properties file:
    host, port, db-file, magic cookie
    Any more items needed?
    4. For configuration(set port, host, db-file name), I think it can only be configured at start. After the program started, any configuration change will take effect after restart. Am I right?
    5. On the networked mode, access to suncertify.properties file need throgh networking( RMI or socket server), right?
    Peter
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Peter,
    1. By using sytem.getProperty("user.dir") to get the directory where suncertify.properties sits, you'll have as many files as you have JVM start directories. If you start the server and a client on the same machine and from the same directory, you'll get one suncertify.properties file. On two different machines and/or if the JVM is started from different directories, you'll have two different files. Notice that you have *no control* on the way your application is started.
    2. If you check your instructions, I think you'll read that the suncertify.properties file *must* be created in the current directory.
    3. host, port and db-file are OK, but magic cookie could be a constant IMO.
    4. It's acceptable IMO and most people here do as you do. Now if you have a server GUI, it's not impossible to change such configuration without restarting the server, but it's not necessary and more complex to code.
    5. No. The suncertify.properties file is always local to the application which uses it.
    Regards,
    Phil.
    Peter Yunguang Qiu
    Ranch Hand

    Joined: Nov 22, 2003
    Posts: 99
    Hi, Phil, Thank you very much.
    Sun's instruction says that suncertify.properties must be located in the current working directory.
    I still have some questions:
    Q1: What does IMO mean? What do "magic cookie could be a constant IMO" and "Its acceptable IMO" mean?
    1. By using sytem.getProperty("user.dir") to get the directory where suncertify.properties sits, you'll have as many files as you have JVM start directories. If you start the server and a client on the same machine and from the same directory, you'll get one suncertify.properties file. On two different machines and/or if the JVM is started from different directories, you'll have two different files. Notice that you have *no control* on the way your application is started.

    Q2: "you'll get one suncertify.properties file", "you'll have two different files". How do I get suncertify.properties file(s)? I think I have to create suncertify.properties file first by

    Then I can load it. Am I right? But it seems different from what you mean. Could you expain?
    "Notice that you have *no control* on the way your application is started." What does this mean?
    5. No. The suncertify.properties file is always local to the application which uses it.

    Q3: On the networked mode, suppose we have 1 server and 100 clients. All of them must have the same properties such as host and port and db-file, right? How these 100 clients get the same properties if they don't read suncertify.properties file from server?
    Q4: You mean magic cookie can not be stored in suncertify.properties file. Why? Where is the suitable place to put it?
    Q5: If I have a server GUI, I have to start it like this:
    java -jar runme.jar server
    The server can be started, stoped and configured by this GUI. The server can also start together with this GUI. Alternatively, I can also start the server by above command line and configure it using client GUI. Right?
    Sorry to bother you too mcuh. I am still confused.
    Peter
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi peter,
    Q1:
    What does IMO mean? What do "magic cookie could be a constant IMO" and "Its acceptable IMO" mean?

    It's the acronym of "in my opinion". I try to not abuse of acronyms (but you just proved that I do ). My 3 other favorites are "AFAIK" (as far as I know), "OOH" (on one hand) and "OTOH" (on the other hand).
    If you are interested, here is the list I use, not to find new ones for personal use, but to translate the ones I don't understand immediately : Net Acronyms.
    Q2: I use a Fa´┐Żade (a class of my own which simplifies properties management) which returns default values in case the file doesn't exist. But of course, what you're doing is correct.
    Q3: Think of this : how would they connect to the server the first time to retrieve the host and port number they need to connect ? Each client has its own property file.
    Q4: You may do it. But, IN MY OPINION (hope you'll notice the effort ), the magic cookie value is unlikely to be changed in the future. So I chose to declare a constant instead : public static final int MAGIC_COOKIE = ...;
    Q5: Sorry, but I don't understand what you mean. What's your question ?
    Regards,
    Phil.
    Peter Yunguang Qiu
    Ranch Hand

    Joined: Nov 22, 2003
    Posts: 99
    Thanks Phil.
    Re: answer to Q3:
    You are right. I am so stupid. The server and clients should have their own properties files if sever and clients are running on different machies. But the properties settings should be the same, right? When server properties(such as port, host) are changed, the client properties have to be changed to the same value as the server, right? In this case, people who in charge of client machines have to be informed, by email, telephone, or what ever. The client machines cannot change properties automaticly, right?
    When running in non-networked mode, there only one properies file, right?
    Re: answer to Q5:
    Sun's instruction says: each part(client and server) must be executable using command of this exact form:
    java -jar <path_and_filename> [<mode>]
    So I use command line:
    java -jar runme.jar server
    to start the server or server GUI. What I mean was, the GUI(window) can be start first, then use the server GUI(by clicking on a button) to start server or configure the server. And, the client can also configure the server by changing the server's properties file.
    You said, "5. No. The suncertify.properties file is always local to the application which uses it." You mean, client cannot access server's properties file if they are running in different machines?
    But if they are running in the same machine(there is only one properties file), client GUI can modify properties file, so, it is not neccessary to have a server GUI, right? The assignment is a single jar file, it include both server and client and cannot seperate server and client, right?
    Peter
    Nicholas Cheung
    Ranch Hand

    Joined: Nov 07, 2003
    Posts: 4982
    Hi Peter,
    Phil has already pointed out how you cater for this issue.

    prefix your property names with "server." and "client." to make sure that server and client property names never collide

    Thus, client can change the client settings, while it will not affect the server settings even both client and server share the same properties file.
    Consider:
    server.file="C:\db-1x2.db"
    client.file="D:\db-1x2.db"
    If the client changes the file location, it affects only client.file.
    So do the server side.
    Nick.
    [ December 28, 2003: Message edited by: Nicholas Cheung ]

    SCJP 1.2, OCP 9i DBA, SCWCD 1.3, SCJP 1.4 (SAI), SCJD 1.4, SCWCD 1.4 (Beta), ICED (IBM 287, IBM 484, IBM 486), SCMAD 1.0 (Beta), SCBCD 1.3, ICSD (IBM 288), ICDBA (IBM 700, IBM 701), SCDJWS, ICSD (IBM 348), OCP 10g DBA (Beta), SCJP 5.0 (Beta), SCJA 1.0 (Beta), MCP(70-270), SCBCD 5.0 (Beta), SCJP 6.0, SCEA for JEE5 (in progress)
    Peter Yunguang Qiu
    Ranch Hand

    Joined: Nov 22, 2003
    Posts: 99
    Thanks Nicholas.
    You mean, when run in networked mode, use server.file, when run in non-netwoked mode, use client.file, right?
    Peter
    joe black
    Ranch Hand

    Joined: Dec 03, 2003
    Posts: 103
    Do you have the configuration GUI load at startup only when there is no properties file, or if the user selects to load it from a menu in the GUI?
    Or do you load the configuration GUI everytime at startup.
    And if you have a server GUI, does it stay visible the whole time the server is running so you can shut it down?
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Joe,
    And if you have a server GUI, does it stay visible the whole time the server is running so you can shut it down?

    That's what I did. My server is a standard application with a GUI, as the client is.
    Regards,
    Phil.
    Peter Yunguang Qiu
    Ranch Hand

    Joined: Nov 22, 2003
    Posts: 99
    Hi, Joe:
    I only have 1 GUI, it shows when the program start. It will show the original config properties value or show default value if the properties file missing. You can change the settings or keep the original. You can set if show config window at start.
    Both server and client use the same suncertify.properties file and use the same values. Is that OK?
    Peter
    joe black
    Ranch Hand

    Joined: Dec 03, 2003
    Posts: 103
    Originally posted by Peter Yunguang Qiu:

    Both server and client use the same suncertify.properties file and use the same values. Is that OK?

    If the client and server are on different machines then you obviously can't use the same suncertify.properties file.
    Peter Yunguang Qiu
    Ranch Hand

    Joined: Nov 22, 2003
    Posts: 99
    If the client and server are on different machines then you obviously can't use the same suncertify.properties file.

    The assignment is packed in a single file "runme.jar". It can run in networked mode or non-networked mode. It CANNOT be seperated. When run in networked mode and in different machines, one copy of runme.jar run on a machine as a server, each client machine must have a seperate copy of runme.jar. Each runme.jar is accompanied with one suncertify.property file, so I don't think two such files are needed. Server and client configuration(such as host, port, db-file-path) must be same. I don't understand in what situation 2 properties files are needed or 1 properties file but 2 sets of value(example: server.port, client.port). Could you explain?
    Peter
    Nicholas Cheung
    Ranch Hand

    Joined: Nov 07, 2003
    Posts: 4982

    I don't understand in what situation 2 properties files are needed.

    Consider the following case:
    The server starts in machine X, while 10 clients connect to the server from machines 1 to 10.
    If, there is only 1 property file, where should it be located?

    1 properties file but 2 sets of value(example: server.port, client.port).

    Consider the following case:
    The machine that acts as the server, may allow "some" *restricted* users to operate as standalone mode, which share the same or different database file.
    For example, for local mode, it uses C:\db-1x2.db.
    For network mode, it uses D:\db-1x2.db
    If there is no prefix, how should the GUI distingish the location?
    In fact, this case may not happen, but using prefix for properties name do no harm, rite?
    Nick.
    Nicholas Cheung
    Ranch Hand

    Joined: Nov 07, 2003
    Posts: 4982

    The assignment is packed in a single file "runme.jar". It can run in networked mode or non-networked mode. It CANNOT be seperated.

    YES. It cannot be separate.
    However, can I do this?
    n+1 machines have an exact copy of runme.jar.
    Machine X does the following:
    java -jar runme.jar server
    Machine 1 to n do the following:
    java -jar runme.jar
    Or even
    Machine Y (one more machine) does the following:
    java -jar runme.jar alone
    I guess all of them are possible, depends on which mode you wanna operating with, or whether they share the same database file.
    Otherwise, how can I connect to a *network* server that provide the resevation services, which the client is NOT located in the same machine as the server? In other words, networked mode is meaningless becos "runme.jar is a single jar file that the client and server cannot be seperated".
    The code cannot be seperated, but the mode can be different, rite?
    Nick.
    George Marinkovich
    Ranch Hand

    Joined: Apr 15, 2003
    Posts: 619
    My thoughts on some of the questions raised on this thread:
    When the executable is running on a machine in standalone mode, I think you can safely assume that it is "standing alone," that is, there is no other executable currently running on that machine. Therefore no database server is needed, no network is used, and no locking is necessary (but may be provided anyway depending on your design).
    I think you can have a server and (multiple) network client(s) running on the same machine. (The client(s) is/are connecting to the server on localhost.) I'm not saying this is practical or useful in the real world I'm just saying it is possible (that is, I take no measures to prevent it from happening).
    I think you can have multiple network clients running on the same machine. Same caveat as above (maybe not practical, but not prevented either).
    I think each executable can have it's own suncertify.properties file, but it's more accurate to say that each working directory can have it's own suncertify.properties file. For example, a single executable, on a single machine, can be run from any number of working directories, each of which can (and should) have its own suncertify.properities file.
    I think the properties of the suncertify.properites file should be the same for all suncertify.properties files. The values of those properties will, of course, be different. In other words, I don't think you need different versions of a suncertify.properties file to support client and server configuration items.
    I think it's also possible to not package a suncertify.properties file in the project.jar file. The executable can be written to use hard-coded default properties in the absence of a suncertify.properties file. The executable can also create it's own suncertify.properties file. An application starting in network client mode must be able to know where on the network the database server is located. This information can be stored in the suncertify.properties file, but it's highly unlikely that the information will be correct the first time the application is run (after installation). Since the user cannot indicate the server host on the command line, the application must have a means of allowing the user to specify this information (such as in the GUI).
    - George


    Regards, George
    SCJP, SCJD, SCWCD, SCBCD
    David Chan
    Ranch Hand

    Joined: Jun 11, 2003
    Posts: 30
    After reading this thread, I have raised a question:
    I agree that in network mode, the client should not know what the db filename is, instead, the server needs to store those values (db filepath, port number) in its own properties file. But according to the sun requirements, to change config value it must be done via a GUI. Then, does it mean server must have a GUI? Thanks for your help.
    David

    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.
    You must not require manual editing of any files by the examiners.
    George Marinkovich
    Ranch Hand

    Joined: Apr 15, 2003
    Posts: 619
    Originally posted by David Chan:
    But according to the sun requirements, to change config value it must be done via a GUI. Then, does it mean server must have a GUI?

    Yes, I don't see any other way of doing it. It seems to me that the executable running in both client and server modes must have a GUI to allow the user to configure such items. We are expressly prohibited from using command-line arguments and told not to require the user to manually edit files. We are told to use the suncertify.properties file and we are expected to have a GUI.
    Hope this helps,
    George
    Jason Mowat
    Ranch Hand

    Joined: Aug 17, 2003
    Posts: 79
    It seems to me that the executable running in both client and server modes must have a GUI to allow the user to configure such items.

    I had this same problem. My solution was to instead have my RMI server run a DbModel factory (a factory object that returns DbModel (or database) objects). The factory has a static method createDbModel(String) bModel. This allows you to start up remote databases with the path being determined by the one in your local properties file. Note that that path will be relevant to the server's directory structure.
    In order for this to work, your DbModel (or whatever you call it) needs to implement Remote. So does your factory interface since it's RMI.
    I really didn't want to make a server GUI. That limits you to which platforms you can run it on (and by that, I mean that if you use a server GUI, your server has to be running a windowing system, like Windows or XWindows).
    Cheers,
    Jason
    Jason Mowat
    Ranch Hand

    Joined: Aug 17, 2003
    Posts: 79
    The factory has a static method .
    Oops :-)
    Cheers,
    Jason
    Jason Mowat
    Ranch Hand

    Joined: Aug 17, 2003
    Posts: 79
    Grrr!
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: suncertify. properties -- Network / non-networked mode