The moose likes JBoss/WildFly and the fly likes JBoss class loading and reading .properties files Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » JBoss/WildFly
Bookmark "JBoss class loading and reading .properties files" Watch "JBoss class loading and reading .properties files" New topic

JBoss class loading and reading .properties files

Dean Schulze

Joined: Jun 13, 2008
Posts: 3
I have a legacy J2EE application where the .ear is structureed like this:





I'm deploying this in JBoss 4.0.3 SP1.

The problem is that all three .war files include the archiveX.jar files in their WEB-INF/lib directory as well. So there are 3 copies of each .jar (sometimes more) in the .ear.

I'm fixing the build.xml files so that the .war applications will share the .jar files at the top level of the .ear file and eliminiate the .jars from each WEB-INF/lib. I've modified each .war file to include a Class-Path: in its so that they all use the .jar files at the top of the .ear file:

Class-Path: commons-beanutils.jar commons-codec-1.3.jar ...

The .war applications find the classes they need so the Class-Path: setting works as far as sharing common .jar files among multiple .war applications.

There's a new problem, however. The applications need to load some .properties files that are in the WEB-INF/classes directories of the respective .war files. Inside webapp2.war, for example, these .properties files are in


The old application (no Class-Path: entry in and the .jar files in WEB-INF/lib) was able to load these .properties files from WEB-INF/classes. After putting the Class-Path: in the so that the top level .jar files are used the .war applications can't load .properties files from WEB-INF/classes.

It appears that putting a Class-Path: in the of a .war drops the WEB-INF/classes directory from the .war classpath in JBoss 4.0.3.

I've solved this by putting the .properties files in the top level of the .ear file, but I don't understand why I have to do this.

Here's how the code loads the .properties files works.

The files to be loaded are prefixed with a '/' like "/". The loading is done by a shared utility class in one of the shared top level .jar files. It creates a FileInputStream like this:

is = this.getClass().getResourceAsStream(fileName);

The javadocs for Class.getResourceAsStream() say:

"The rules for searching resources associated with a given class are implemented by the defining class loader of the class. This method delegates to this object's class loader."

So maybe the issue isn't with with the Class-Path: dropping WEB-INF/lib from the class loader's classpath.

I believe that JBoss uses one class loader to load the top level .jar files and different class loaders for the .war applications. I'm speculating that when code in a .war calls a method in a class in one of the top level .jar files the relevant class loader is the one that loaded the top level .jar file and not the one that loaded the .war file (which would include WEB-INF/lib in its classpath).

The JBoss docs are, uh, in flux at the moment so they haven't been much use.

Can anyone shed some light on what is going on?

Jaikiran Pai

Joined: Jul 20, 2005
Posts: 10441

Dean, Welcome to JavaRanch

The way i used to manage a similar application on JBoss-4.0.x was to place those jars at the top level of the EAR and make an entry for them in the application.xml (as a java module):

This way the archiveX.jar is available to all the components in the EAR which includes those war files. You don't have to add the archiveX.jar entries in the MANIFEST.MF of the WAR files.

I do agree that if the number of such common archiveN.jar keep increasing then the application.xml becomes ugly.

However, starting JBoss-4.2.x there's a very clean and easy way to manage this. You can create a folder named lib at the root of the EAR and place all your common jars (which are required by various components in the EAR) in this lib folder. JBoss will by default add all these jars to the classpath of the application and make them available to all the components in the EAR. You don't have to do anything with the application.xml nor the MANIFEST.MF in the war. If upgrading to JBoss-4.2.x is an option for you, then i would recommend you use the latest stable 4.2.2 GA version.

[My Blog] [JavaRanch Journal]
Dean Schulze

Joined: Jun 13, 2008
Posts: 3
Thanks for pointing out the use of <module>. Since it is in application.xml it should be portable, and is probably a little less work than adding a Class-Path to each .war application's

I'm still trying to understand the issue with reading .properties files in the .war applications, though.
I agree. Here's the link:
subject: JBoss class loading and reading .properties files
It's not a secret anymore!