VerifyError on Tomcat 7 production server probably caused by Apache Commons Logging 1.0.4
我正在Tomcat 7上开发webapp。在本地版本的Tomcat上一切正常,但是在生产服务器上部署它时,会引发此异常。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | java.lang.VerifyError: (class: org/apache/commons/logging/impl/Log4JLogger, method: fatal signature: (Ljava/lang/Object;Ljava/lang/Throwable;)V) Incompatible object argument for function call at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2595) at java.lang.Class.getConstructor0(Class.java:2895) at java.lang.Class.getConstructor(Class.java:1731) at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410) at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351) at org.apache.fop.apps.FopFactory.<clinit>(FopFactory.java:68) at cz.soma.tomcat.generator.DokumentaceUtils.createPdfDocument(DokumentaceUtils.java:818) at cz.soma.tomcat.generator.FileFactory.createPdfDocument(FileFactory.java:58) at cz.soma.tomcat.generator.Generator.doPost(Generator.java:111) at javax.servlet.http.HttpServlet.service(HttpServlet.java:650) at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) |
当我尝试
1 2 3 4 5 6 7 8 | try { logConstructor = logClass.getConstructor(logConstructorSignature); return (logConstructor); } catch (Throwable t) { throw new LogConfigurationException ("No suitable Log constructor" + logConstructorSignature+" for" + logClassName, t); } |
此后称为java.lang.Class函数并引发异常。
您知道什么原因,为什么错误仅在生产服务器上引发,而不在我的本地计算机上引发?
为什么会发生此错误(java.lang.VerifyError)?
java.lang.VerifyError将是在针对与运行时(在生产服务器中)使用的库不同的库进行编译时的结果。
建议1:
您可以使用
资源链接:http://www.java-samples.com/showtutorial.php?tutorialid=674
建议#2:
如果使用的是maven,则在pom.xml中添加此依赖项,
1 2 3 4 5 | <dependency> <groupId>commons-logging</groupId> commons-logging</artifactId> <version>1.1.1</version> </dependency> |
并从pom.xml
中删除以下依赖项
1 2 3 4 5 | <dependency> <groupId>commons-logging</groupId> commons-logging</artifactId> <version>1.0.4</version> </dependency> |
资源链接:获取java.lang.ClassNotFoundException:org.apache.commons.logging.LogFactory异常
建议3:
templatetypedef发现了问题并给出了2个解决方案
A VerifyError usually means that you loaded in a class file that is
somehow malformed or which references another class file that has
changed in a way that causes the code in another class file to no
longer be valid. For example, if you compiled a class file that
referenced a method in some other class, then independently modified
and recompiled the second class after altering that method's
signature, you'd get this sort of error.I'd suggest doing a clean build and seeing if this issue goes away. If
not, check whether you're using up-to-date JARs and source files.
资源链接:https://stackoverflow.com/a/5411528/2293534
建议4:
如果本地服务器和生产服务器之间的JDK版本不匹配,请尽可能使其相同。您也可以尝试使用其他JDK版本和其他计算机进行编译。
资源链接:出现java.lang.VerifyError
的原因
希望对您有所帮助。
在生产Tomcat服务器上的公共lib目录中,您可能具有不同版本的日志记录jar。让某人检查\\\\\\\\ lib目录,然后查看lib目录中是否有任何日志记录jar。要么删除这些jar以便使用本地应用程序jar,要么确保在您的应用程序中定义了相同版本的依赖项。
如果要尝试本地复制,请将生产lib目录中的一组jar复制到本地安装。