具有相同jar的Java类加载器

Question

I know that many subject speak about classpath loader and transitive dependancy but im little confused.

I m working on a legacy application that use spring 2.0.5 and spring-ws and all work fine from the beginning of the project to now. And recently we are faced to a runtime problem with a an exception like methodnotfoundexception.

In fact we see that spring-ws depend on spring-2.5. So maven transitive dependancy add spring 2.5 in my webinf/lib directory near spring 2.0.5

But i dont understand why all working fine during many years and now why weblogic decide to load spring2.5 before spring2.0.5 and cause this error?

We have correct the problem and now im looking for same jar with different version and do build failure when i have a conflit to avoid dependancy problem in the future.

But i just want to understand why weblogic decide to load one or another jar ? Because if its alphabetical order, same jar will be loaded all the time, but in my exemple the order change... So i don t understand clearly whats happened.

Thanks by advance;)

Answer 1

While it is documented that WEB-INF/classes is loaded before WEB-INF/lib , the documentation is not clear in cases like yours - where there are sibling copies of Spring in the WEB-INF/lib .

In Tomcat it is alphabetical, but looks like Websphere, Jboss and Weblogic are random. See https://stackoverflow.com/a/5817890/327426

From some threads on the Oracle forums, the recommendation is to run the Classloader Analysis Tool available at http://docs.oracle.com/cd/E23943_01/web.1111/e13706/classloading.htm#BABHJGJJ for your app and see the results. This tool will identify classloading conflicts.

See similar issue at https://community.oracle.com/thread/2387921?tstart=0

This post from 2009 http://www.coderanch.com/t/472496/BEA-Weblogic/Loading-order-jar-WEB-INF on Weblogic v9.2 states "Checking the logs I see the .jars in WEB-INF/lib are being loaded in reverse alphabetical order". This may or may not be true for your version

Another option is to use Maven to bypass the transitive import being packaged in the WAR