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 ]
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...
Joined: Feb 21, 2014
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
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.
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.
Customer surveys are for companies who didn't pay proper attention to begin with.