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.
|
Previous
Index
Next
Flat
Small inconvenience with classpath
Edit
Reply
Quote
