This week's book giveaway is in the OCAJP forum.
We're giving away four copies of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) and have Khalid A Mughal & Rolf W Rasmussen on-line!
See this thread for details.
Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Properties files - directory structure

 
Joshua Fix
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65115
89
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That should work fine. Tools like Hibernate and Log4J do it all the time.
 
Raghavan Muthu
Ranch Hand
Posts: 3381
Mac MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Generally it is placed in "WEB-INF/classes" directory and you can get it using the way you said earlier.
 
Joshua Fix
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65115
89
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Joshua Fix
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Adam Asham
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Jeremy McNally
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
Jeremy McNally
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65115
89
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18277
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic