java.lang.ClassNotFoundException / java.lang.NoClassDefFoundError after updating to EAP 6.4 CP9

Solution Unverified - Updated

Environment

  • Red Hat JBoss Enterprise Application Platform (EAP)
    • Updated to 6.4 Cumulative Patch (CP) 9

Issue

  • Getting the following error after applying Cumulative Patch (CP) 9 to EAP 6.4
Caused by: java.lang.NoClassDefFoundError: javax/ws/rs/core/UriInfo
        at java.lang.Class.getDeclaredFields0(Native Method) [rt.jar:1.7.0_95]
        at java.lang.Class.privateGetDeclaredFields(Class.java:2509) [rt.jar:1.7.0_95]
        at java.lang.Class.getDeclaredFields(Class.java:1819) [rt.jar:1.7.0_95]
        at org.jboss.as.server.deployment.reflect.ClassReflectionIndex.<init>(ClassReflectionIndex.java:57) [jboss-as-server-7.5.9.Final-redhat-2.jar:7.5.9.Final-redhat-2]
        at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:68) [jboss-as-server-7.5.9.Final-redhat-2.jar:7.5.9.Final-redhat-2]
        ... 10 more
Caused by: java.lang.ClassNotFoundException: javax.ws.rs.core.UriInfo from [Module "custom-service.war:main" from Service Module Loader]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.7.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.7.Final-redhat-1]
  • Updating from 6.4.8 to 6.4.9 causes java.lang.NoClassDefFoundError
Caused by: java.lang.NoClassDefFoundError: javax/servlet/jsp/tagext/TagSupport
	at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_79]
	at java.lang.ClassLoader.defineClass(ClassLoader.java:800) [rt.jar:1.7.0_79]
	at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.7.Final-redhat-1]
	at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.7.Final-redhat-1]
	... 19 more
Caused by: java.lang.ClassNotFoundException: javax.servlet.jsp.tagext.TagSupport from [Module "deployment.test.ear:main" from Service Module Loader]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.7.Final-redhat-1]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.7.Final-redhat-1]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.7.Final-redhat-1]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.7.Final-redhat-1]
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.7.Final-redhat-1]
	... 23 more
  • We noticed when testing 6.4.9 that we suddenly had to add a number of dependencies in our ear's manifest.mf that we never had to add before. Specifically, they are javax.jms.api, javax.persistence.api, and javax.xml.ws.api.
    In all previous versions, including 6.4.8, we never had to add any custom dependencies in the manifest file. I didn't see any specific changes that would have caused this in terms of config file changes between 6.4.8 and 6.4.9 so I am wondering if this change was intended or if it is a bug.

Resolution

Root Cause

This content is not included.This content is not included.https://bugzilla.redhat.com/show_bug.cgi?id=1358822

SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.