This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Properties Files and ResourceBundle Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Properties Files and ResourceBundle" Watch "Properties Files and ResourceBundle" New topic
Author

Properties Files and ResourceBundle

Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Hello All!
Can I use a .properties file with a java.util.ResourceBundle to read in certain constants? Wanted to know if anybody has any thoughs or comments regarding this.
Thanks
-Amish
Ta Ri Ki Sun
Ranch Hand

Joined: Mar 26, 2002
Posts: 442
I did for the front end captions etc, and am thinking about one for the back end as well, for error messages, but I might just pass on that.
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
I think it's a great idea.
M


Java Regular Expressions
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Max,
I am planning to use the properties file for puttting constants such as database file name, database location, is in network mode etc.... However I just found out from my requirements that
You must not require the editing of any files by the examiner.

If the examiner has a different database file name or wants to switch from a network mode to a local mode they will have to edit my properties file. Any suggestions???
-Amish
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Well, not all operations need to be fully configurable by the user. E.g. there's no requirement that the user should be able to edit error messages and button text. If this stuff were hardcoded there'd be no question - the user doesn't need to edit those things. If you put this stuff in a ResourceBundle, the user still doesn't need to edit it really, so you can still omit GUI edit capability for these properties. However using properties or ResourceBundle may make future changes easier.
If the examiner has a different database file name or wants to switch from a network mode to a local mode they will have to edit my properties file. Any suggestions???
I think these two options should be explicitly controllable by the user without editing. (Unlike button text, etc. discussed above.) In the Contractors assignment there are specific instructions about how the user controls network s. local - it's done from the command line at program startup. As for DB file name/location - I'd make it one of the things you can configure via GUI when you start the program in server mode, or standalone. (But not client - a client just needs to know where the server is; the server can decide what DB file it will use.)
Does that help?


"I'm not back." - Bill Harding, Twister
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Thanks for the reply Jim,
I agree that the options mentioned ( is in network mode, path to db and name of db) should be on the client side and the client should control that.
But I have one question
But not client - a client just needs to know where the server is; the server can decide what DB file it will use

I can definetly do that, but I will be restricting my server to serve only one db file. When client tells me the path and name of the db file my server has a potential to serve more than one db file. Just wondering if this might be a problem?
-Amish
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Well, that's possible too. And elsewhere I do say that I'd like the DB classes to not be singletons, so that later they could be used for multiple DB files if desired. So your idea is sort of similar. However I don't think that clients should have to know anything about the directory structure and file names on the server. First, it may be undesireable from a security standpoint - should clients be able to browse the server's directory structure in order to find the DB file they want? Or if they can't browse - how will they know if they have the right file name?
And secondly, what if the server administrator decides that the server DB files should be moved to another directory? If clients choose the DB file themselves, then moving the DB file will mean that all the clientss saved preferences for DB file location are now incorrect - each client will have to reconfigure the next time the program is run. And how will they know what the new location should be? This requires extra communication.
On the other hand, if only the server know the DB file location, then when the DB file is moved, only the person who runs the server needs to reconfigure. Everyone else can just continue using their old configurations, as if nothing happened. I think this is preferable unless there's a compelling reason to let clients choose their DB file - and I don't see one, so far.
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Hi Amish,
If you wanted to be fancy, you could store the servername and port in a property /preferences file after first use: thereafter, you can have those fields pre populated with their last choice.
All best,
M
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Jim,
Sorry for the late reply.
You are right that clients should not have the knowledge of directory structures and name of the db file. But as I said before by not doing this on the client side the server can only serve one file and I have made by server to serve more than one client ( Not Singleton ). However I feel there is one more thing I can do. I will put the name of the db file and path to the db file in the .properties file. I will also let the client have the option to pass me the name of the db file and path to the db file as program arguments. Now if they pass me as program arguments I will use that otherwise I will use the path and name from the properties file. In this way I will satisfy sun's requirement where if they want to change the path of the db file and name of the db file they can pass me as arguments and not edit the properties file.
Now considering the scenario that you put forward where if the server administrator want the user to point to a different db file in a different directory structure. They will have to provide the user with a new properties file that has that info.
This solution seems to me more reasonable and I can still let the server be more modular or more functional.
Let me know your comments!
-Amish
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Hi Max,
That is also a nice option, however do read my above post and let me know what you think?
-Amish
Originally posted by Max Habibi:
Hi Amish,
If you wanted to be fancy, you could store the servername and port in a property /preferences file after first use: thereafter, you can have those fields pre populated with their last choice.
All best,
M
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Originally posted by Amish Patel:
Jim,
Sorry for the late reply.
You are right that clients should not have the knowledge of directory structures and name of the db file. -Amish

Hi Amish,
It seems to me that it's immaterial what we think the client should know this information: the requirements seem to require it. What I have suggested in the past is for developers to offer aDialog to capture this information every time the client is started up.
This dovetails nicely with your own suggestion of then preserving the actual information in a properties file, so that it will be available for later pre filling.
All best,
M
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[MH]: It seems to me that it's immaterial what we think the client should know this information: the requirements seem to require it.
I think the requirements are ambiguous. Mine say:
the program must allow the user to specify the location of the database.

What's "location" mean? From a client perspective, I think that being able to specify the host and port number of the server is sufficient to qualify for "location". Has anyone gotten feedback from Sun on this? Any submitted assignments that were evidently docked points for not letting a client speicfy file path?
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
I has always assumed they meant the actual db.db file, since they made a point out of telling us we could place it anywhere we wanted to. Even if there's some sort of indirection( like might have with a web URL), I imagine that the client would know.
M
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Hmmm, could go either way, IMO. I've sent Sun an e-mail in case they wish to clarify. Will post results here.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Sun's response: "The vagueness is deliberate."
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
That's somewhat vague..
M
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Yeah. Here's the text of my e-mail:
-------------------------------------------------
[personal contact info deleted]
Note: I realize the following issue may have been deliberately left vague as part of the exam process, and thus no additional info may be available. If so, I understand; thanks for your time.
----
The question:
Does a remote client need to be able to specify the file name and path for the DB file on the server? Surely the *server* needs this configurability, as does a standalone client. Does a networked client need it though?
----
Discussion, if you care:
The instructions state "the program must allow the user to specify the location of the database." However "location" is vague. Certainly it seems the client needs to be able to choose the server host name and port number. IMO that may be sufficient to say the client has specified a "location". Let the client choose their server; let the server choose the file location. However the client *could* also specify a file path. Is this desireable?
PRO:
1. It may be required by instructions.
2. Allows more flexibility for future enhancements like having several different DB files representing different tables.
CON:
1. May not be required; instructions are vague.
2. More complex to code - server needs ability to serve different files to different clients.
3. May be security risk to allow clients to access arbitrary files on the server. This can be fixed with a security manager, but that's more complexity.
4. May be less conventient for server admin. What if they want to move the files to another location? Need to notify all clients of new location.
Cons 3 and 4 may be ignored as "out of scope" I suppose, and 2 may be answered with "that's your job, deal with it."
Any clarification is appreciated. Thank you...
- Jim Yingst
-------------------------------------------------
I guess I encouraged brevity with that opening note. But I'm interpreting the response as an acknowledgement that yes, the client spec is vague, which means that the wishes of the client can be legitimately interpreted either way. So we can implement a solution either way, unless we find some strong argument for preferring one over the other. IMO as usual.
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Jim,
I interpret the instructions as you do : let the client choose their server (except in stand-alone mode); let the server choose the file location.
However the client *could* also specify a file path. Is this desireable?

I see one more con : Is this feasible ? Nothing in the instructions tell us that the server file system is accessible trhough a LAN from the client machine, nor that it's OS is compatible with the client's one. How to use a JFileChooser on a Windows client machine to browse files on a remote unix server ? Is that feasible ? (I've no experience in that field, so I just wonder).
Regards,
Phil.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
I don't think it's feasible in general, no. Note without a more involved protocol to allow the client to browse the server. Like FTP, for example. But as Max points out, the client could still supply a path, even without having browsing access. We use URLs that way to some extent. Though usually we get the URL from another web page, and the browser does the work of extracting the URL from HTML and using it as the target of a new HTTP request. I suppose clients might have a list of valid file paths supplied to them via e-mail or a web page - then the cut and past a path into our GUI config screen. Still seems rather icky to me though; I'm not going to be supporting that.
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Hi Jim,
Thanks for contacting Sun in this matter. After looking at the pro's and con's I have to think more about it. But I am limited to what I can do because currently my server already handles more than one db file. I went through the extra hassle. However one good thing from this is that the server can serve more than one file.
Thanks
-Amish
S Bala
Ranch Hand

Joined: Jul 15, 2003
Posts: 49
Hi All,
Is it ok to interpret the database path differently for the networked and the stand alone mode.
1) For the networked mode, the database path reflects the path to the database server.(ie where the server is running). The server implicitly knows where the physical database is located.
2) For the stand alone mode the path reflects the physical path to the database.

Thanks,
SB
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi SB
Yes, that is one way to interpret the instructions, and many people here seem to be following that concept.
Regards, Andrew


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

Joined: Jul 18, 2003
Posts: 183
I've created a properties file that contains the file names for both the server and client, the server url and port. When starting the server it looks up the file to connect to from the properties file and ignores the client stuff. When starting the remote client, it uses the url and port to find the server (who has already connected to a file). When starting in standalone mode the client uses the local file name from the properties file to find the file.
I've created a generic properties editor dialog that allows the user to configure these properties (or any others for that matter) from the client.


ms<br />SCJP, SCJD
Svetlana Koshkina
Ranch Hand

Joined: Jul 08, 2003
Posts: 108
I'm very pleased that I read this thread because I already packaged my assignment in which I compeletly forgot to implement this "must allow to specify location" thing. I had to stand on my head (almost literally) to figure out how to refactor with min. impact. I ended up with solution that can be interpreted as the client specifying the location. Keeping in mind that some servers expose very limited space to clients to choose from. I have a lot of indirection but at the end everything is made up so as client point to the server where the file resides. No doubt about that.
Wow, anyway, I could've submitted old version and failed or something!
Thanks to all.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Properties Files and ResourceBundle
 
Similar Threads
Common resource for all configurable parameters.
How not to hard-code file location in java?
Passing runtime parameters to EJB
WA #1.....word association
Bound & Constraints properties