0x34

0x34

关注
发信
关注(28)粉丝(399)

ClassNotFoundException仅取决于JDK7更新版本吗?

本文介绍了ClassNotFoundException仅取决于JDK7更新版本吗?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我继承了一个JBOSS 4.2.3.GA.ear项目，如果我使用JDK 7u45进行构建，那么所有内容都可以加载并正常运行，但无法加载和运行.如果我使用JDK 7的任何较新版本(例如7u76、7u79、7u80)进行构建，则可以在JBoss Bootstrap中早期运行.

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

JBOSS服务器本身在Java 1.7.0_45上运行.

The JBOSS server itself runs on Java 1.7.0_45.

失败的记录原因是实际存在的类的ClassNofFoundException(即使是发生故障的.ear):

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)

通常，我会很容易找到真实引发ClassNofFoundException的原因，但这次我很困惑，考虑到以下事实:

Normally, I would easily find a real reason for a ClassNofFoundException, but this time I am baffled, considering the following facts:

  1. .ear的整个环境(包括 CLASSPATH ！)是相同.

  1. The entire environment (including the CLASSPATH!) for the .ear is identical.

前面提到的未找到的类" dbs.common.logger.CsvLayout 位于中，位于common.jar文件中，路径与假定的路径完全相同.

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.

在其他人的开发工作站(相同的Eclipse等)上，使用JDK 7u79(即，比7u45更新的版本)构建.ear，会导致.ear正确加载并运行(在同一服务器和环境上) ).

On someone else's development workstation (same Eclipse, etc.) building that .ear with JDK 7u79 (i.e. later update than 7u45), results in a .ear that properly loads and runs (on same server and environment).

什么可能解释此类ClassNofFoundException?

我想念什么?

更新:比较工作和不工作的common.jar文件中的未找到" CsvLayout.class，表明类文件格式.工作的是0x33(Java SE 7)，失败的是0x34(Java SE 8).

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

我一直在始终仅使用jre7的执行环境时非常小心. 0x34是如何潜入的?

I have been careful to always work with Execution Environments that are jre7 only. How did that 0x34 sneak in?

推荐答案

问题来自以下事实:库 common.jar :是使用Java 8构建的，没有指定目标类文件版本，并且因此会生成具有Java 8类文件版本的jar文件.

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.

要使用Java 8构建Java 7类文件，您需要

To build Java 7 classfile with Java 8 you need to

  • 纯Java编译:添加目标选项javac -target 1.7 <javafile>
  • 行家:添加属性<maven.compiler.target>1.7</maven.compiler.target>
  • ant:在您的build.xml中添加<property name="ant.build.javac.source" value="1.7"/> <property name="ant.build.javac.target" value="1.7"/>
  • 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

这篇关于ClassNotFoundException仅取决于JDK7更新版本吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

07-22 13:30
Powered by LMLPHP ©2024 0x34 0.039721