问题
I inherited a JBOSS 4.2.3.GA .ear project in which everything loads and runs fine if I build it with JDK 7u45, but fails to load & run early in the JBoss Bootstrap if I build it with any newer update of JDK 7 (e.g. 7u76, 7u79, 7u80).
The JBOSS server itself runs on Java 1.7.0_45.
The logged reason for the failure is a ClassNofFoundException for a class that is actually there (even for the failing .ear):
log4j:ERROR Could not create the Layout. Reported error follows.
java.lang.ClassNotFoundException: dbs.common.logger.CsvLayout
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:190)
at org.apache.log4j.helpers.Loader.loadClass(Loader.java:178)
at org.apache.log4j.xml.DOMConfigurator.parseLayout(DOMConfigurator.java:555)
at org.apache.log4j.xml.DOMConfigurator.parseAppender(DOMConfigurator.java:269)
at org.apache.log4j.xml.DOMConfigurator.findAppenderByName(DOMConfigurator.java:176)
at org.apache.log4j.xml.DOMConfigurator.findAppenderByReference(DOMConfigurator.java:191)
at org.apache.log4j.xml.DOMConfigurator.parseChildrenOfLoggerElement(DOMConfigurator.java:523)
at org.apache.log4j.xml.DOMConfigurator.parseCategory(DOMConfigurator.java:436)
at org.apache.log4j.xml.DOMConfigurator.parse(DOMConfigurator.java:999)
at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:867)
at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:773)
at org.apache.log4j.xml.DOMConfigurator.configure(DOMConfigurator.java:901)
at org.jboss.logging.Log4jService$URLWatchTimerTask.reconfigure(Log4jService.java:643)
at org.jboss.logging.Log4jService$URLWatchTimerTask.run(Log4jService.java:582)
at org.jboss.logging.Log4jService.setup(Log4jService.java:460)
at org.jboss.logging.Log4jService.createService(Log4jService.java:476)
at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:260)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:243)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at com.sun.proxy.$Proxy0.create(Unknown Source)
at org.jboss.system.ServiceController.create(ServiceController.java:330)
at org.jboss.system.ServiceController.create(ServiceController.java:273)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at com.sun.proxy.$Proxy4.create(Unknown Source)
at org.jboss.deployment.SARDeployer.create(SARDeployer.java:260)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at com.sun.proxy.$Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:508)
at java.lang.Thread.run(Thread.java:744)
Normally, I would easily find a real reason for a ClassNofFoundException, but this time I am baffled, considering the following facts:
The entire environment (including the CLASSPATH!) for the
.earis identical.The aforementioned "not found class" dbs.common.logger.CsvLayout is in the common.jar file in exactly the same path where it is supposed to be.
There are no errors in the build whatsoever.
On someone else's development workstation (same Eclipse, etc.) building that
.earwith JDK 7u79 (i.e. later update than 7u45), results in a .ear that properly loads and runs (on same server and environment).
What could possibly explain such ClassNofFoundException?
What am I missing?
Update:
Comparing the "not found" CsvLayout.class between the working and not working common.jar file, shows that there is a difference in the major_version of the class file format. The working one has 0x33 (Java SE 7), the failing has 0x34 (Java SE 8).
I have been careful to always work with Execution Environments that are jre7 only. How did that 0x34 sneak in?
回答1:
The problem comes from the fact that the library common.jar: is built using java 8 without specifying the target classfile version, and so a jar file with java 8 class file versions is generated.
To build Java 7 classfile with Java 8 you need to
- pure java compilation: add the target option
javac -target 1.7 <javafile> - maven: add the property
<maven.compiler.target>1.7</maven.compiler.target> - ant: add
<property name="ant.build.javac.source" value="1.7"/> <property name="ant.build.javac.target" value="1.7"/>to your build.xml
来源：https://stackoverflow.com/questions/44256470/classnotfoundexception-dependent-on-jdk7-update-version-only