3 Replies Latest reply on Sep 27, 2008 2:00 PM by peterj

    Yet another isolated classloader question

    tomstrummer Sep 26, 2008 3:04 PM

      I am trying to create a simple web app built with Maven. Maven by default will package all dependencies in the WAR, which causes classloader issues if those libraries are also already in JBoss.

      Ok, so I thought classloader isolation solved this problem, but apparently I'm not understanding it correctly. The error is that ELResolver was already loaded (the el-api JAR is in my WAR under /WEB-INF/lib):

      Caused by: java.lang.ClassNotFoundException: Unexpected error during load of: javax.el.ELResolver, msg=loader constraint violation: loader (instance of org/jboss/mx/loading/UnifiedClassLoader3) previously initiated loading for a
 different type with name "javax/el/ELResolver"
 at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:560)
 at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:415)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
 at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)


      Here's my jboss-web.xml. My understanding was that this means I get an isolated classloader that will use the classes in my WAR only and not those of the app server: 
      <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 2.4//EN"
 "http://www.jboss.org/j2ee/dtd/jboss-web_4_0.dtd">
<jboss-web>
 <class-loading>
 <loader-repository>seam.jboss.org:loader=pjm-mule.war
 <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
 </loader-repository>
 </class-loading>
</jboss-web>


      What am I doing wrong? Am I absolutely forced to remove this JAR from my WAR? I have a similar problem with an EAR but this is a much simpler example. Thanks in advance for the help.

      • 2713 Views
      • Tags:
        • 1. Re: Yet another isolated classloader question
          peterj
          peterj Sep 26, 2008 8:07 PM (in response to tomstrummer)

          This does not directly answer your question, but why are you not using the "provided" scope. Example:

          <dependency>
 <groupId>commons-logging</groupId>
 <artifactId>commons-logging</artifactId>
 <version>1.1</version>
 <scope>provided</scope>
</dependency>


          This way your WAR will not be filled with JARs that are already provided by JBossAS.




            • Actions
          • 2. Re: Yet another isolated classloader question
            tomstrummer Sep 27, 2008 8:51 AM (in response to tomstrummer)

             

            "PeterJ" wrote:
            This does not directly answer your question, but why are you not using the "provided" scope.


            In my case they are all transitive dependencies that need to be excluded. So yes, I could add them as top level provided dependencies or add them as 'excludes' but it is a pain.

            Plus, in other cases, say I want to include the latest Hibernate libraries. I hit the same classloader problem that I thought isolation was supposed to solve.

              • Actions
            • 3. Re: Yet another isolated classloader question
              peterj
              peterj Sep 27, 2008 2:00 PM (in response to tomstrummer)

              Isolation, while handy, is not infallible. Let's say that class A uses class B which in turn uses class C. Classes A and C are in your isolated EAR. Classes B and C are in the lib directory. You now have a problem because the "C" you are using is from the lib directory, not the EAR. The solution to this situation is to also package B within the EAR. In many cases this is possible, in some cases it is not, especially if the standard Java EE libraries are involved.

              One way to resolve such situations is to set the -verbose:class JVM command-line option. This option causes the classloaders to print out each class loaded and the JAR file the class came from. This might help solve the isolation issue.

              As far as the Maven transitive dependencies go, I cannot think of any way around it that would not be more painful.

                • Actions