views:

220

answers:

2

I could not find a clear answer to this question elsewhere, so I'll try here:

Is there some way (programmatic or other) to get a list of JARs/classes loaded by an Application Classloader in the precise order they were loaded? By Application Classloader I mean the classloader that loads an EAR application in an applications server (WLS, WAS, JBoss...), but obviously, it applies to any classloader.

So, to generalize, what I would like to find out is the list and order of JARs loaded by a specified classloader. Not individual classes, that is easy enough to find out by calling the classloader.getPackages(), but a list of JAR files that were loaded by this classloader.

+1  A: 

Have you tried to use the JVM option -verbose:class. It displays all loaded JAR files and classes.

Example:

[Opened C:\Program Files\JDK160~1\jre\lib\rt.jar]
[Loaded java.lang.Object from C:\Program Files\JDK160~1\jre\lib\rt.jar]
Steve
Thanks, Steve - yes, I tried that option and it works fine if you are just interested in knowing which classloader and from what .jar loaded a specific class. The output gets too overwhelming though, as our application has thousands of classes :). I've used an approach similar to what kdgregory suggested - see below.
Marina
+1  A: 

The short answer is no. Classloaders are not required to expose their search logic.

However, if your classloader instance happens to be URLClassLoader or a subclass, then you do have access to the list of jars/directories, via the getURLs() method. Per the doc for this class, those URLs will be searched in order.

In practice, if you're trying to find out where a class is being loaded from, Steve's answer is probably more useful.

kdgregory
Thanks, kdgregory. This is the approach I finally used - basically I wrote a utility that figures out the classloader hierarchy at runtime and queries each classloader what list of resources they 've loaded using the getURLs() method if available. It worked well for both WLS and WAS. In the case of WLS, their own classloaders do not extend URLClassloader, but they do have a different method, getClassPath(), which returns an ordered list of classpath entries. And all WAS classloaders seem to extend the URLClassloader, so getURLs() worked fine. Have not tried it on JBoss yet.Marina
Marina