Catalin
stranger
Reged: 08/18/03
Posts: 4
|
|
Hi,
I agree with the author that loading properties from a file using file access classes is not a really good idea.
However, here is a problem I've run into with properties loaded from classpath.
First of all, the reason we use property files in the first place, instead of hardcoding the properties in the code, is because we want the people who use the application to be able to change them.
Also, we usually deliver application packed as jar files (or another kind of archive, such as war, ear).
But what must the user do in order to change some properties? First of all, he must locate the property file inside the archive. Next, he must unpack the archive, change the desired properties, and pack the archive again... Seems to me a lot of trouble for the poor user! Not to mention signed jar files, where the problems are even bigger!
Just how many times did you find yourself looking through some ".jar" files looking for a "jndi.properties" file? And what if you find the file twice in the classpath? which one is loaded?
Seems to me that in this case, the user has much more trouble than just editing a good old fashioned /etc/someapp.conf file (I know, portability issues, etc.), but...
So, I think that also loading property files from classpath has some benefits, it also seems to have some drawbacks as well, which should not be disregarded.
|
vlad_roubtsov
member
Reged: 06/21/03
Posts: 169
|
|
I have several counter-arguments:
(a) you say
Quote:
First of all, the reason we use property files in the first place, instead of hardcoding the properties in the code, is because we want the people who use the application to be able to change them.
That is not always true. I may use a .properties classpath resource to contain some application defaults that I, the author of the application, may want to change in the future releases and I don't want them hardcoded in Java. The user won't even know that I have such a resource. The JDK itself comes with a ton of property files like that (just look under <jdk dir> for anything that matches *.properties) and nobody seems to be complaining about that.
(b) you say
Quote:
But what must the user do in order to change some properties? First of all, he must locate the property file inside the archive. Next, he must unpack the archive, change the desired properties, and pack the archive again... Seems to me a lot of trouble for the poor user! Not to mention signed jar files, where the problems are even bigger!
Just how many times did you find yourself looking through some ".jar" files looking for a "jndi.properties" file? And what if you find the file twice in the classpath? which one is loaded?
Seems to me that in this case, the user has much more trouble than just editing a good old fashioned /etc/someapp.conf file (I know, portability issues, etc.), but...
Ok, now let's say that you do want user-editable properties. But I don't follow you connection from editable properties to them necessarily being loaded as java.io.Files.
What if you told the user to edit a .properties file located, say, in <jre dir>\classes -- is that really hard? You can load this as a classpath resource and the changes will be picked up on the next JVM restart.
(c) finally, there are tons of resources that the user might know about but will never have to edit. For example, let's say your application can parse user XML files written to a certain (well-known) XML schema. You can load the .xsd schema definition as a classloader resource, can't you? The user never has to edit that.
Or as another example, instead of hardcoding all label/frame/etc titles in you Swing code, why not put them in a classpath .properties definition? This way you separate your visual content from the actual implementation. You can later localize it or fix typos by merely editing the non-compilable resource and again the user never touches such properties.
Or if not text labels, consider .gif icon images instead: why do you expect the user to ever want to edit them? Surely you can load them as a classloader resource as well.
A Java application of any reasonable level of complexity will have several such resources that are best loaded via classloaders. And for properties that are specific to an individual user's experiences (e.g., the size of his/her Swing windows etc) there is always the java.util.prefs API (load your defaults as a classpath resource and save user changes via java.util.prefs, registry, etc)...
|
Catalin
stranger
Reged: 08/18/03
Posts: 4
|
|
Hi
I agree about properties that are not user editable (except with the example with labels, which is a i18n issue, and should be kept as resource boundle).
I was reffering to application properties that are user editable (note that I say user editable properties, not user preferences, there is a clear distinction between these two concepts). I am sorry I did not make it clear in my previous post.
However, I think that the solution with a directory that contains the configuration porperties, and that the user (or shell script that starts the app) must add to classpath does not have more benefits than loading the properties using java.io.File (the config dir can be pased to the application as a system property by the startup script, or by the user).
However, sometimes the second solution could be "cleaner" than the first one (I am thinking about the example with a properties file that appears twice in classpath).
This is what I wanted to point out in my previous post, sorry again I did not make it clear.
|
vlad_roubtsov
member
Reged: 06/21/03
Posts: 169
|
|
Quote:
However, I think that the solution with a directory that contains the configuration porperties, and that the user (or shell script that starts the app) must add to classpath does not have more benefits than loading the properties using java.io.File (the config dir can be pased to the application as a system property by the startup script, or by the user).
<jre dir>\classes does not need to be passed to the application as it is already implicitly in the classpath.
|
Anonymous
Unregistered
|
|
I think you missed the point. Who will deploy properties file in the jre/classes directory? Doesn't seem the logical choice for deployment. Also, modifying the editable properties at runtime is a must for server based applications. Using the classpath doesn't have any benefits over file based approach. We used file based since you don't have to worry about classloaders, it is easy to detect file changes and the properties file is independent of the war or ear file.
|
Anonymous
Unregistered
|
|
How to detect file changes in java?
I do not think it is easy
|
Unregistered
|
|
Use getResource() instead of getResourceAsStream(), then use openConnection() instead of openStream(). From that URLConnection object you can getLastModified() and getInputStream() if the time is different than the last.
|
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
