Forums Register Login

Properties files - directory structure

+Pie Number of slices to send: Send
Is there some convention for what directory to place custom properties files in? I want to write a utility API and include it as a JAR. The servlet context will get me access to the "web" directory, and I usually put the files in /WEB-INF, but helper classes that don't have access to the servlet context seem to only be able to find resources in the "classes" directory by using the Thread.currentThread().getContextClassLoader().getResourceAsStream(filename) method.

So is it proper to put my custom config files in the classes folder? Or perhaps classes/properties/ or something? I just want a method that will find the resource if called from a standard Java project or if called from a servlet.
+Pie Number of slices to send: Send
That should work fine. Tools like Hibernate and Log4J do it all the time.
+Pie Number of slices to send: Send
Generally it is placed in "WEB-INF/classes" directory and you can get it using the way you said earlier.
+Pie Number of slices to send: Send
Thanks for your replies.

I wanted to create a properties class that holds static references to default values. The class will attempt to load the config file, but if it does not find it, write the default values to a new config file. Is it possible to get some type of pointer for writing to the classes folder if no resource exists there?
+Pie Number of slices to send: Send
Writing to the classes folder after deployment? Why? I wouldn't touch that with a ten-foot pole. That means that your build and your deployment are now out of sync.

Why do you feel the need to write to the classes folder?
+Pie Number of slices to send: Send
The only thing I feel the need to do is be able to read and write properties files with my API being called from either a standalone Java program or from a servlet. The saving part is very optional, but the expectation is still that the properties file will be edited with custom settings per deployment.

As I stated in my original post, the only way I can find to do this is using a current thread's context class loader. And my first question was "is it proper to put my custom config files in the classes folder"... I'd love for somebody to help me understand where these properties files should live and the proper way to access them.
+Pie Number of slices to send: Send
One thing to keep in mind is that a Java web app can but doesn't have to be deployed from the server's file system. They can be deployed as a packed war file and can be deployed remotely. In these cases, there is no 'classes' directory to which you can write. To make your application as portable as possible, you might consider keeping these dynamic config files somewhere other than in your web application's directory structure. You can then use a context init param to configure the location of these files.
Then, instead of looking for them on the classpath, read them using a FileReader with the path from the init param.
+Pie Number of slices to send: Send
Ben, that's a good point. But where would you recommend to store these settings then so that the file is stored in a location that makes sense in server (Linux, Unix) environments as well as in Windows?

I have not given this much thought but what do you think of such a file system structure?


Or would it be a better option to use the preferences API? What I don't like with it is that it stores the XML-files in the JRE (or was that the JDK?) dir, so when you move the application to another server or upgrade the JRE it's easy to forget to copy the settings too! It'd be better to keep all the files under the same roof so to speak.
[ October 17, 2008: Message edited by: Adam Asham ]
+Pie Number of slices to send: Send
You can put your custom properties files in a Resources folder under your project root. Dependent on how you want to use them, there are various methods of doing it that you can research. I usually just create my own folder for my properties files under the project root. Others may do it differently... You can do it right under your SRC folder if you want too...
+Pie Number of slices to send: Send
If you listened to my post, you could (in the Application-Context.xml) use the PropertyPlaceholderConfigurer class in a bean declaration if you are using Spring and declare your properties files there as

<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name = "locations">
<list>
<value>dfedfd.properties</value>
</list>
</property>
</bean>

Than you would create a bean that with getters and setters. Inside the app context xml file you can set those properties to the names of your properties in your properties file. Check it out. Could help. Other ways of doing this too.
+Pie Number of slices to send: Send
 

Jeremy McNally wrote:You can do it right under your SRC folder if you want too...


The source doesn't get included in the war file. Something in the build (or IDE settings) needs to make sure that the folder is properly built into the war file.
+Pie Number of slices to send: Send
The java.util.Properties class, along with the property bundle functions give you a very flexible way of keeping and accessing properties in an application, including the option to switch in and out locale-specific properties such as error messages in different languages and to "stack" property objects so that lower-level property object values get inherited by higher-level property objects. You also have the option on where to source static property values from, for example by having a properties text file(s) loaded into a Property object.

Within a WAR, as mentioned, property files should be treated as read-only objects because the strict J(2)EE specs don't permit writing into WARs. You can get around this by injecting dynamic values into the Properties class objects and since loaded property files can be either classpath objects or external file objects, general configuration info can be placed in files that are external to both the WAR and the appserver hosting the WAR.

Which is what I do. In order to avoid hard-coding OS- and implementation-dependent filesystem paths for customizable properties, I set up a webapp Resource definition that contains the path, then use JNDI to retrieve that resource and give me the filesystem path from which to read the properties.

In fact, if you have only a few simple read-only property values, you can just set them all in JNDI.
Mo-om! You're embarassing me! Can you just read a tiny ad like a normal person?
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 2885 times.
Similar Threads
Servlet doing accessing ejb
different classpath for context
how to access init/property parameters inside bean classes
How to read properties files from outside Container?
Cannot Access EJB on Weblogic ???
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 16:34:47.