my dog learned polymorphism
The moose likes Servlets and the fly likes Properties files - directory structure Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "Properties files - directory structure" Watch "Properties files - directory structure" New topic
Author

Properties files - directory structure

Joshua Fix
Ranch Hand

Joined: Sep 18, 2007
Posts: 57
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.


SCJP 5.0
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 63342
    
  70

That should work fine. Tools like Hibernate and Log4J do it all the time.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Raghavan Muthu
Ranch Hand

Joined: Apr 20, 2006
Posts: 3381

Generally it is placed in "WEB-INF/classes" directory and you can get it using the way you said earlier.


Everything has got its own deadline including one's EGO!
[CodeBarn] [Java Concepts-easily] [Corey's articles] [SCJP-SUN] [Servlet Examples] [Java Beginners FAQ] [Sun-Java Tutorials] [Java Coding Guidelines]
Joshua Fix
Ranch Hand

Joined: Sep 18, 2007
Posts: 57
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

Joined: Jan 10, 2002
Posts: 63342
    
  70

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

Joined: Sep 18, 2007
Posts: 57
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

Joined: Dec 11, 2004
Posts: 13410

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.


Java API J2EE API Servlet Spec JSP Spec How to ask a question... Simple Servlet Examples jsonf
Adam Asham
Greenhorn

Joined: Jul 06, 2006
Posts: 13
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

Joined: Feb 21, 2014
Posts: 108
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

Joined: Feb 21, 2014
Posts: 108
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

Joined: Jan 10, 2002
Posts: 63342
    
  70

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

Joined: Jun 25, 2001
Posts: 17145
    
  27

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.


An IDE is no substitute for an Intelligent Developer.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Properties files - directory structure
 
It's not a secret anymore!