How can I get around this classloader hierarchy problem?

Question

I run iplanet's java applcation server, something in it is loading commons-logging-1.0.4.jar

That's fine until one of my applications calls AuthSSLProtocolSocketFactory which is another apache library that also uses commons logging. I put the jar on the jvm classpath and get this error

Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy....

It seems that commons logger doesn't like having two instances of itself loaded in different classloaders. I assume the application server has its own classloader that's loading it the first time (Although I can't find any appserver configuration that mentions it) so when my application goes to load it a second time it throws that exception.

I can't change the webserver, and I can't change the apache library. Suggestions?

Answer 1

Take a look at SLF4J.

Additionally, http://www.qos.ch/logging/classloader.jsp will help.

Answer 2

Not familiar with iplanet, but in WebSphere you can set your applications classloading policy to be PARENT_LAST. This will then load everything in your applications classloader before looking at the parent. This should resolve this kind of problem, assuming your have a similar setting.

This does mean that you will have to supply all the dependencies in your own application (which is the best practice anyway).

Answer 3

Are you putting commons logging in your classpath explicitly? You said jvm classpath, so I assume you are specifying it on the command line when you start iPlanet. That's not the recommended way to load jars in J2EE apps.

The easiest thing is to just let the Apache library use the commons logging jar that comes with iPlanet. Don't put commons-logging.jar in your WEB-INF/lib dir or in any classpath setting and the iPlanet one should be picked up automatically.