Yes, Class Loaders are a bit scary. But you can slay the beast when armed with the right information. There are 3 types of Class Loaders you can use:
1) The System ClassLoader
2) The Current ClassLoader
3) The
Thread Context ClassLoader.
You can access the System ClassLoader by calling ClassLoader.getSystemClassLoader(). In most
J2EE application servers, the System ClassLoader is too high in the hierarchy and will not find the resources packaged in your application�s EJB JAR or WAR. In JBoss, using the System ClassLoader is still a problem because the ClassLoader Repository holds references to all deployed applications, so you could easily have a naming conflict if more than one application uses the same class.
The Current ClassLoader is the ClassLoader that loaded the class that contains the method that�s currently executing. Class.getResource() and the one-parameter version of Class.forName() use the Current ClassLoader by default. The Current ClassLoader is a better choice than the System ClassLoader, but there are still problems with using the Current ClassLoader:
� You may not know who calls your class, and the current ClassLoader could be up too high in the ClassLoader to find the resources that your class needs.
� In JBoss, you could have the same naming conflict with Class Loader Repository that you had with the System ClassLoader.
You gain access to the current Thread Context ClassLoader by calling Thread.currentThread().getContextClassLoader(). The Thread Context ClassLoader is the ClassLoader used by the creator of the Thread that runs your code. The Thread Context ClassLoader works in a way that�s contrary to the Delegation Model by enabling a parent ClassLoader to access classes from any of its child ClassLoaders. Sometimes a parent ClassLoader needs to see classes that one of its child ClassLoaders instantiates at runtime. Use the Thread Context Class Loader for the following reasons:
� In JBoss, you�re guaranteed to load the class or property file from your application by using the Thread Context ClassLoader. Even though the JBoss ClassLoader Repository may have the same class or property from several applications, the Thread Context ClassLoader picks the class or property that belongs to your application.
� The EJB specification forbids EJBs to use the Current Class Loader, and since the System Class Loader isn�t a workable option, you�re left with the Thread Context ClassLoader. See the Programming Restrictions section in the EJB specification for further details.
So here's the bottom line: Get the Thread Context ClassLoader so you can find your properties file in your EAR/WAR/EJB JAR. Here's how to get the props file. First, use the following utility class:
---
import java.io.*;
import java.net.*;
import java.util.*;
public class ResourceLoader {
/**
* Making the default (no arg) constructor private
* ensures that this class cannnot be instantiated.
*/
private ResourceLoader() {}
public static Properties getAsProperties(
String name) {
Properties props = new Properties();
URL url = ResourceLoader.getAsUrl(name);
if (url != null) {
try {
// Load the properties using the URL (from the CLASSPATH).
props.load(url.openStream());
} catch (IOException e) {
}
}
return props;
}
public static URL getAsUrl(String name) {
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
return classLoader.getResource(name);
}
}
---
Then, make the following call in your code:
Properties myProps = ResourceLoader.getAsProperties("MyProps.properties");
I hope this helps.
Tom Marrs
Lead Author, JBoss at Work: A Practical Guide