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.
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?
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?
Joined: Sep 18, 2007
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.
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.
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 ]