• 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

NX: About the db file

 
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When I start the server program,should I let user choose the db file from a FileChooser dialog?
I just read the db file in current directory now. Is it ok?
Could you tell me something about it? I didn't find the instruction request for server GUI...
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think you should allow the user to enter the db file as a parameter when starting the server. I don't think a graphical interface for choosing the file is a good idea for a server
 
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi James,

Originally posted by james wang:
When I start the server program,should I let user choose the db file from a FileChooser dialog?
I just read the db file in current directory now. Is it ok?
Could you tell me something about it? I didn't find the instruction request for server GUI...


Your assignment instructions may include the following sections:


Network Approaches
Your choice of RMI or serialized objects will not affect your grade, but
no other approach is acceptable. In either case, the program must allow
the user to specify the location of the database
, and it must also
accept an indication that a local database is to be used, in which case,
the networking must be bypassed entirely. No authentication is required
for database access.


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>]
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.


If so, then I think the bolded sections establish both the need for allowing the user to specify the database file location, as well as the need for the application to do this via a GUI. Given these requirements I believe that when your application runs in server mode it must have a GUI that at a minimum allows the user to specify the database file location. You may also decide to allow the user to specify the port number that will be used when the network client contacts the database server.
Hope this helps,
George
[ February 12, 2004: Message edited by: George Marinkovich ]
 
Jamy Wang
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi George, thank you for your help. Yes, my assignment instructions does include what you had post! I am so careless
But I'm still a little cofused about "suncertify.properties" file. Is it necessary for the assignment? Because I think I don't need the config file...


java -jar <path_and_filename> [<mode>]
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.


[Andrew: changed [code] block to [quote] block so that wrapping works]
[ February 16, 2004: Message edited by: Andrew Monkhouse ]
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi James,

Originally posted by james wang:

But I'm still a little cofused about "suncertify.properties" file. Is it necessary for the assignment? Because I think I don't need the config file...


Well if I didn't convince you the first time I'll have to take another go at it. So quoting from my assignment instructions again:

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.


There sure are a lot of musts in there. How are you going to persist the configuration information between runs of the program if not "stored in a file called suncertify.properties which must be located in the current working directory." I don't think it's really a matter of interpretation, they're suggesting it would be a very wise thing to use the suncertify.properties file. In fact, they seem to be insistent about it. If I were you I would take the hint.
The configuration information is not in any sense optional. For example, they tell you that you need to allow the user to specify the location of the database file. How are you going to allow the user to do that? Remember you can't use command-line arguments to do that. I think the suncertify.properties is the way to go here. Also, doesn't the host name (and arguably the port number as well) of the database server need to be configurable. If it's not configurable how in the world are you going to know beforehand what the name of the tester's database server host is? There are aspects of the assignment that are ambiguous or debatable, I just don't think this is one of them.
Hope this helps,
George
 
Jamy Wang
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, George. Thank you very much for your reply.


There sure are a lot of musts in there. How are you going to persist the configuration information between runs of the program if not "stored in a file called suncertify.properties which must be located in the current working directory." I don't think it's really a matter of interpretation, they're suggesting it would be a very wise thing to use the suncertify.properties file. In fact, they seem to be insistent about it. If I were you I would take the hint.
The configuration information is not in any sense optional. For example, they tell you that you need to allow the user to specify the location of the database file. How are you going to allow the user to do that? Remember you can't use command-line arguments to do that. I think the suncertify.properties is the way to go here. Also, doesn't the host name (and arguably the port number as well) of the database server need to be configurable. If it's not configurable how in the world are you going to know beforehand what the name of the tester's database server host is? There are aspects of the assignment that are ambiguous or debatable, I just don't think this is one of them.


Sorry, I don't know if I made mistakes. Can't I allow the user input host name and port by a dialog? Why I need a config file? Every time the client try to connect to the server, it should input the host and port in server mode, or the db file location in standalone mode. And the server side, every time you start the server, user should input port number and choose the db file location(by a FileChooser). Will be OK? Should I save the history information in the config file, suncertify.properties? For the next time run?
I just want to know if the config file is necessary, because I am afraid of auto-fail. I'm sorry for trouble you, do you mind to correct what I said?
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi James,

Originally posted by james wang:
I just want to know if the config file is necessary, because I am afraid of auto-fail. I'm sorry for trouble you, do you mind to correct what I said?


Yes, the suncertify.properties file is absolutely necessary. First of all, Sun mentions a suncertify.properties file in the assignment instructions (that alone would be enough for me). I think you should take that fact as a giant HINT that you should use such a file. The assignment instructions have a requirement that the executable be configurable and then they prohibit you from using command-line arguments (which would have been one way to make the executable configurable). So, although the assignment instructions do not state this directly, they are indirectly saying: you must have a GUI for each operating mode of the executable that allows the user to enter configuration parameters. Further, the assignement instructions go on to say that these configuration parameters must be persistent and then they suggest (Hint, HINT, HINT!!!) that you use the suncertify.properties file to satisfy this requirement.
Maybe this will do the trick. Imagine you don't use a suncertify.properites file. This means that the executable has no memory of what the user did the last time the executable was run. Effectively your executable would have no memory (kind of like the movie "50 First Dates") of the configuration parameter that the last user specified. This is an undesirable situation. The following scenario illustrates what happens when you don't use a suncertify.properties file and then when you do.
WITHOUT a suncertify.properties file:
The user starts your application in standalone mode. Your application prompts him for the location of the database file. The user enters the database file. Your application displays the main GUI with the JTable. The user is happy. The user exits the application.
The user starts your application in standalone mode again. Your application prompts him (again?) for the location of the database file. The user wonders why he has to keep telling the application where the bloody database file is located. The user enters the database file. Your application displays the main GUI with the JTable. The user is mildly perturbed. The user exits the application.
The user starts your application in standalone mode (again). Your application prompts him (AGAIN!?! ) for the location of the database file. The user swears at the screen: "can't this application remember what I told it from one run to the next!". The user starts asking his colleagues where the programmer who developed this application lives. Your application displays the main GUI with the JTable. The user is in a pretty foul mood. The user exits the application.
You have to start wearing wearing a disguise to work....
WITH a suncertify.properties file:
The user starts your application in standalone mode. Your application looks for a suncertify.properties file, but since it doesn't find one it uses your hard-coded defaults. If your hard-coded defaults work, then the user is never prompted to enter the database file location. However, if the hard-coded defaults don't work, then your application prompts him for the location of the database file. The user enters the database file. Your application writes the changes to the suncertify.properties file. Your application displays the main GUI with the JTable. The user is happy. The user exits the application.
The user starts your application in standalone mode. Your application looks for a suncertify.properties file, finds it and gets all it's configruation parameters from this file (including the location of the database file). Your application displays the main GUI with the JTable. The user thinks: application, it didn't even ask me where the database file is located, it REMEMBERED. The user is happy. The user exits the application.
You don't have to wear a disquise to work...
So you can use the suncertify.properties file, or you start shopping for that disguise. The choice is yours.
Hope this helps,
George
 
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi james:
Fist look Ken's idea pls, you perhaps get some good suggestion:

Application
========
When launched, the app displays a dialog to get the location using either hard-coded defaults or params from the properties file if it was previously created. My interpretation of location is:
Standalone - db file pathname
Network Server - db file pathname and port no.
Network Client - hostname and port no.


Why use suncertify.properties, I can tell you firmly--This is sun requirement. Like must to use locking mechanism in your application.
 
Jamy Wang
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi George, thank you for your lively words
Hi Leo, thank you too!
I think the config file is necessary, for it make the config persistent between runs of the program.
Thank you again!
reply
    Bookmark Topic Watch Topic
  • New Topic