ClassLoader Hierarchy viewer

I always had problems with class loading. Be it a Java EE app or some proprietary framework that maintains its own class loader hierarchy, I would end up spending time on “Why my class is not getting loaded” kind of problems. I’m sure may of the developers/designers would have faced this problem if they are deploying a Java EE app (.ear) on a commercial app container. This is quite common problem when migrating your app from one app server to another one to make it “deploy-anywhere” app.

I looked for some kind of tool that shows me classloader hierarchy on an application (server) at a given instance of time. I never succeeded in finding such tool. I saw such utility for websphere servers.. but thats specific to webSphere app server.

So, I ended up writing a tool that shows me this hierarchy. I used the concept of “agents” introduced in Java 5. The purpose of the agents was to do the class file instrumentation [One way of writing aspects if you are familiar with AOP]. Though I did not attempt to modify the class bytes, I used it to build the tree of class loaders with each node in the tree refers to the actual classloader.

Details

It has basically two parts -

1) The agent that sniffs the class loading information and builds a structure with that information.

2) The client that reads this structure and displays in user friendly format.

I’m going to talk about just the usage here. You can see for my next post for few more details on this.

1. The sniffer

This is java agent jar.

Usage: — Update that script that starts the application/server to be examined to add a vm arg as shown below:

-javaagent:clsniffer.jar

Make sure you keep clsniffer.jar in the application’s base directory.

Thats it.. You can just forget about it. Whenever your application starts it keeps capturing the class loading information. Unlike profilers, it doesn’t hamper the performance, so you can keep it all the time.

The client

There is a choice here for you to capture the information the way you want.

The client(s)

a. Eclipse plugin

Download the eclipse plugin ( suman.analysis.classloaderview_1.0.0.jar) and keep it in the plugins directory of your eclipse.

Start the debug session in eclipse [it works both local and remote debugging] and when the debugger stops at your break point, go to “Window->Show view->General->ClassLoader View”, you would be presented with the full hiearchy of class loaders and the associated classes for each classloader. Exciting??

Btw, this is not matured enough, so you need to do be patient..

If you don’t see the hierarchy properly, following this:

a) Make sure you have a debug session running and is stopped at a (any) break point.

b) Hit the refresh (<-) button on the view to reload the view till you see the correct values.

b. Another client

If you don’t use eclipse for any weird reason, you can still use this utility. Just add the following watch expression on any debugger of your choice.

Class.forName(“agents.analysis.ClassLoaderSniffer”).getMethod(“getCLForest”).invoke(null)

And you’d see a properly indented tree of classloaders as the result. [see the screen shots below]. You don’t see classes here though.

Downloads

You can get the downloadables for this utility here.

Leave a comment for any bugs/suggestions on improvements.

Tail piece

This can be done in Groovy in a better way on Java 6 which has scripting support. You can get the JSR223 compatible scripting engine it from here.