6 Replies Latest reply on May 29, 2017 9:57 AM by Tomaz Cerar

    After patching EAP 6.4.9 to 6.4.13 we have a class loading issue

    Peter Schmid Newbie

      We patched our JBoss EAP 6.4.9 to 6.4.13. Our application (.ear) uses the OSLC4J library which is Apache Wink based. Therefore we excluded javaee.api via jboss-deployment-structure.xml:

       

      <?xml version="1.0" encoding="UTF-8"?>

      <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">

       

          <ear-subdeployments-isolated>false</ear-subdeployments-isolated>

         

          <deployment>

              <exclude-subsystems>

                <subsystem name="jaxrs" />

                <subsystem name="resteasy" />

                <subsystem name="webservices" />

              </exclude-subsystems>

         

               <exclusions>

                  <module name="javaee.api" />

               </exclusions>

       

               <dependencies>

                  <!--

                      find com.sun.net.httpserver.HttpPrincipal out of jre/lib/rt.jar:

                      see http://stackoverflow.com/questions/12492717/jboss-7-1-1-add-rt-jar-of-jre-to-classpath

                   -->

                  <system export="true">

                      <paths>

                          <path name="com/sun/net/httpserver"/>

                      </paths>

                  </system>

                  <module name="com.oracle.ojdbc6" />

              </dependencies>

          </deployment>

       

          <sub-deployment name="subdeployment.war" >

               <exclusions>

                  <module name="javaee.api" />

               </exclusions>

          </sub-deployment>

       

      </jboss-deployment-structure>

       

      After the patch we get a runtime exception like this:

       

      java.lang.ClassNotFoundException: javax.servlet.http.HttpServletRequest from [Module "deployment.eASEE-oslc-proxy-ear-1.0.0.39401.ear:main" from Service Module Loader]

              org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)

              org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)

              org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)

              org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)

              org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)

              org.eclipse.lyo.oslc4j.core.OSLC4JUtils.resolveURI(OSLC4JUtils.java:203)

              org.eclipse.lyo.oslc4j.provider.json4j.AbstractOslcRdfJsonProvider.writeTo(AbstractOslcRdfJsonProvider.java:127)

              org.eclipse.lyo.oslc4j.provider.json4j.OslcRdfJsonArrayProvider.writeTo(OslcRdfJsonArrayProvider.java:85)

              org.eclipse.lyo.oslc4j.provider.json4j.OslcRdfJsonArrayProvider.writeTo(OslcRdfJsonArrayProvider.java:38)

              org.apache.wink.server.internal.handlers.FlushResultHandler.handleResponse(FlushResultHandler.java:199)

              org.apache.wink.server.handlers.AbstractHandler.handleResponse(AbstractHandler.java:38)

              org.apache.wink.server.handlers.ResponseHandlersChain.handle(ResponseHandlersChain.java:26)

              org.apache.wink.server.handlers.ResponseHandlersChain.handle(ResponseHandlersChain.java:22)

              org.apache.wink.server.handlers.AbstractHandlersChain.doChain(AbstractHandlersChain.java:63)

              org.apache.wink.server.handlers.AbstractHandler.handleResponse(AbstractHandler.java:39)

              org.apache.wink.server.handlers.ResponseHandlersChain.handle(ResponseHandlersChain.java:26)

              org.apache.wink.server.handlers.ResponseHandlersChain.handle(ResponseHandlersChain.java:22)

              org.apache.wink.server.handlers.AbstractHandlersChain.doChain(AbstractHandlersChain.java:63)

              org.apache.wink.server.handlers.AbstractHandler.handleResponse(AbstractHandler.java:39)

              org.apache.wink.server.handlers.ResponseHandlersChain.handle(ResponseHandlersChain.java:26)

              org.apache.wink.server.handlers.ResponseHandlersChain.handle(ResponseHandlersChain.java:22)

              org.apache.wink.server.handlers.AbstractHandlersChain.doChain(AbstractHandlersChain.java:63)

              org.apache.wink.server.internal.log.Responses.handleResponse(Responses.java:90)

              org.apache.wink.server.handlers.ResponseHandlersChain.handle(ResponseHandlersChain.java:26)

              org.apache.wink.server.handlers.ResponseHandlersChain.handle(ResponseHandlersChain.java:22)

              org.apache.wink.server.handlers.AbstractHandlersChain.doChain(AbstractHandlersChain.java:63)

              org.apache.wink.server.handlers.AbstractHandlersChain.run(AbstractHandlersChain.java:48)

              org.apache.wink.server.internal.RequestProcessor.handleRequestWithoutFaultBarrier(RequestProcessor.java:212)

              org.apache.wink.server.internal.RequestProcessor.handleRequest(RequestProcessor.java:154)

              org.apache.wink.server.internal.servlet.RestServlet.service(RestServlet.java:119)

              javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

              com.bosch.de.cdgsmt.emt4.oslc4j.scm.filter.UAESFilter.doFilter(UAESFilter.java:58)

       

      OSLC4J imports Glassfish servlet libraries for compilation. I suspect at runtime OSLC4J tries to refer to the HttpServletRequest provided by the Glassfish .jar and gets JBoss's own implementation. Maybe I'm completely wrong...

       

      Any help would be highly appreciated. Thank you!

        • 1. Re: After patching EAP 6.4.9 to 6.4.13 we have a class loading issue
          Anup Dey Apprentice

          This can happen when you've placed server-specific libraries in the webapp's /WEB-INF/lib or probably JRE/lib. Big chance that you copied Tomcat's /lib/servlet-api.jar into there. You shouldn't do that. This would only lead to collisions in the classpath which leads to this kind of errors and it will make your webapp unportable (i.e. it is tied to run on Tomcat only, you can't run it at another servers like Glassfish, JBoss AS, Websphere, etc). You should keep the server-specific libraries at their default location. Cleanup the /WEB-INF/lib from any server-specific libraries and cleanup JRE/lib from any 3rd party libraries.

          You probably copied server-specific libraries there because you wasn't able to compile your servlets. Copying the libraries in /WEB-INF/lib is the wrong solution. You should basically just specify those libraries in the compiletime classpath. Since you're using Eclipse, this can be done easily: first add Tomcat in Servers view, then associate your webapp project with the integrated Tomcat instance. This way Eclipse will automatically add the server-specific libraries to the project's buildpath. On a brand new web project you can choose the server during project creation wizard. On existing web projects, you can modify it in Targeted Runtimes section in project's properties.

          Check your lib/maven jar structure.

          When you are compiling classes which are importing something from javax.servlet package, you need to have that dependency on your class path.

          For example when you have public class FooServlet extends HttpServlet, then the Java compiler needs to be able to get javax.servlet.http.HttpServlet to check whether the parent is not final, whether you are implementing all abstract methods, etc.

          • 2. Re: After patching EAP 6.4.9 to 6.4.13 we have a class loading issue
            Peter Schmid Newbie

            Thank you for your quick reply. Things are bit more complicated, I'll go more into the details:

             

            Our .ear application uses the OSLC4J library in version 2.1.0 which has this dependency:

             

                <dependency>
                       <groupId>org.glassfish</groupId>
                       <artifactId>javax.servlet</artifactId>
                       <version>3.1-b33</version>
                       <scope>provided</scope>
                </dependency>

             

            This library consist of several files some of which we just adapted to our needs - we included the library source code into our project and removed the library jars from our build dependencies. The core OSLC4J library is taken as-is. When some class in the library accesses the HttpServletRequest injected via the @Context annoation the exception seen above is thrown. I just added this class's source code to our project and the exception is no longer thrown.

             

            What exactly is the reason for the ClassNotFoundException in the first case and how do we solve this issue in a proper way?

             

            Thank you for your help!.

            • 3. Re: After patching EAP 6.4.9 to 6.4.13 we have a class loading issue
              ehugonnet Apprentice

              You are providing a Java EE API class which conflicts with the server's own.

              • 4. Re: After patching EAP 6.4.9 to 6.4.13 we have a class loading issue
                Tomaz Cerar Master

                can you post list of jars you have in your deployment

                 

                your.ear/lib/*.jar

                and

                your.ear/*.war/WEB-INF/lib

                 

                this it he only way we can help you with what is going wrong.

                • 5. Re: After patching EAP 6.4.9 to 6.4.13 we have a class loading issue
                  Peter Schmid Newbie

                  The JARs with 1.0.0.40164 in their names are application specific

                   

                  ear/lib:

                  activation-1.1.1.redhat-4.jar

                  antlr-2.7.7.jar

                  antlr-runtime-3.2.jar

                  commons-codec-1.9.jar

                  commons-lang-2.3.jar

                  commons-logging-1.2.jar

                  core-1.0.0.40164.jar

                  jboss-security-1.0.0.40164.jar

                  httpclient-4.5.2.jar

                  httpcore-4.4.4.jar

                  jaxb-api-2.2.jar

                  jcl-over-slf4j-1.7.7.jar

                  jena-core-2.7.1.jar

                  jena-iri-0.9.1.jar

                  jsr311-api-1.1.1.jar

                  log4j-1.2.17.jar

                  mybatis-3.1.1.jar

                  oslc4j-core-2.1.0.jar

                  oslc4j-core-extended-1.0.0.40164.jar

                  oslc4j-query-1.0.0.40164.jar

                  oslc4j-scm-1.0.0.40164.jar

                  slf4j-api-1.7.7.jar

                  slf4j-log4j12-1.7.7.jar

                  stax-api-1.0-2.jar

                  stringtemplate-3.2.jar

                  xercesImpl-2.10.0.jar

                  xml-apis-1.4.01.jar

                   

                  war/lib:

                  oslc-proxy-ejb-1.0.0.40164.jar

                  geronimo-annotation_1.1_spec-1.0.jar

                  icu4j-3.4.4.jar

                  iri-0.8.jar

                  jaxb-impl-2.2.jar

                  jena-2.6.4.jar

                  oslc4j-jena-provider-1.0.0.40164.jar

                  oslc4j-wink-2.1.0.jar

                  stax-api-1.0.1.jar

                  wink-client-1.2.1-incubating.jar

                  wink-common-1.2.1-incubating.jar

                  wink-json4j-1.2.1-incubating.jar

                  wink-json4j-provider-1.2.1-incubating.jar

                  wink-server-1.2.1-incubating.jar

                   

                  Thank you for your support!

                  Peter

                  • 6. Re: After patching EAP 6.4.9 to 6.4.13 we have a class loading issue
                    Tomaz Cerar Master

                    Peter Schmid wrote:

                     

                    ear/lib:

                    activation-1.1.1.redhat-4.jar <-- remove, part of jdk

                    antlr-2.7.7.jar <-- probably safe to remove, but  test first

                    antlr-runtime-3.2.jar <-- same as above

                    commons-codec-1.9.jar

                    commons-lang-2.3.jar

                    commons-logging-1.2.jar <-- safe to remove, app server provides it for you

                    core-1.0.0.40164.jar

                    jboss-security-1.0.0.40164.jar <-- remove as it is part of app server

                    httpclient-4.5.2.jar

                    httpcore-4.4.4.jar

                    jaxb-api-2.2.jar <-- remove as it is part of app server & jdk

                    jcl-over-slf4j-1.7.7.jar <-- safe to remove, app server provides it for you

                    jena-core-2.7.1.jar

                    jena-iri-0.9.1.jar

                    jsr311-api-1.1.1.jar <-- remove this is part of app server and / or jdk

                    log4j-1.2.17.jar <-- safe to remove

                    mybatis-3.1.1.jar

                    oslc4j-core-2.1.0.jar

                    oslc4j-core-extended-1.0.0.40164.jar

                    oslc4j-query-1.0.0.40164.jar

                    oslc4j-scm-1.0.0.40164.jar

                    slf4j-api-1.7.7.jar <-- safe to remove, app server provides it for you

                    slf4j-log4j12-1.7.7.jar <-- safe to remove, app server provides it for you

                    stax-api-1.0-2.jar <-- remove as this is part of jdk & app server

                    stringtemplate-3.2.jar

                    xercesImpl-2.10.0.jar <-- probably safe to remove, but test first

                    xml-apis-1.4.01.jar <-- probably safe to remove, but test first

                     

                    war/lib:

                    oslc-proxy-ejb-1.0.0.40164.jar

                    geronimo-annotation_1.1_spec-1.0.jar <-- remove, not needed at runtime, it can just cause problems

                    icu4j-3.4.4.jar

                    iri-0.8.jar

                    jaxb-impl-2.2.jar <-- remove as this is part of jdk & app server

                    jena-2.6.4.jar

                    oslc4j-jena-provider-1.0.0.40164.jar

                    oslc4j-wink-2.1.0.jar

                    stax-api-1.0.1.jar <-- remove, part of jdk & app server

                    wink-client-1.2.1-incubating.jar

                    wink-common-1.2.1-incubating.jar

                    wink-json4j-1.2.1-incubating.jar

                    wink-json4j-provider-1.2.1-incubating.jar

                    wink-server-1.2.1-incubating.jar