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

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

peter_schmid Apr 25, 2017 5:27 AM

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>

<exclude-subsystems>

</exclude-subsystems>

</exclusions>

<!--

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

-->

<paths>

</paths>

</system>

</dependencies>

</deployment>

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

</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

andey Apr 26, 2017 7:19 AM (in response to peter_schmid)

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.
Actions

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

peter_schmid May 26, 2017 5:37 AM (in response to andey)

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 May 29, 2017 3:11 AM (in response to peter_schmid)

You are providing a Java EE API class which conflicts with the server's own.
Actions
4. Re: After patching EAP 6.4.9 to 6.4.13 we have a class loading issue

ctomc May 29, 2017 5:11 AM (in response to peter_schmid)

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.
Actions
5. Re: After patching EAP 6.4.9 to 6.4.13 we have a class loading issue

peter_schmid May 29, 2017 6:35 AM (in response to ctomc)

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
Actions
6. Re: After patching EAP 6.4.9 to 6.4.13 we have a class loading issue

ctomc May 29, 2017 9:57 AM (in response to peter_schmid)

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
Actions

Go to original post