JAVA Drp项目实战—— Unable to compile class for JSP 一波三折

 

       交代下背景。电脑系统是64位的，用的是64位的Tomcat。安装是32位的Myeclipse10，java环境也是32位的。Tomcat在開始启动时会报这样一个错误，“Can't load IA 64-bit .dll on a AMD32-bit platform”。可是不耽误使用，近期在敲Drp项目中用到了底层接口的几个方法，这个错误导致项目不能正常执行了，所以就将64位的Tomcat换成了与java环境一样的32位的Tomcat。上面的问题就顺利攻克了，于是继续自己的开发，可是当JSP页面启动时就出现了我们这篇文章要说的错误“Unableto compile class for JSP”。

 

以下是这个错误的具体信息：

严重:Servlet.service() for servlet [jsp] in context with path [/drp5.9] threwexception [Unable to compile class for JSP:
 
An error occurred atline: [33] in the generated java file: [D:\计算机\学习课程\第三年\3.J2EE\2DRP_Java项目视频_王勇\MyDrp\drp\apache-tomcat-7.0.55-windows-x86\apache-tomcat-7.0.55\work\Catalina\localhost\drp5.9\org\apache\jsp\login_jsp.java]
The methodgetJspApplicationContext(ServletContext) is undefined for the type JspFactory
 
Stacktrace:] withroot cause
org.apache.jasper.JasperException:Unable to compile class for JSP:
 
An error occurred atline: [33] in the generated java file: [D:\计算机\学习课程\第三年\3.J2EE\2DRP_Java项目视频_王勇\MyDrp\drp\apache-tomcat-7.0.55-windows-x86\apache-tomcat-7.0.55\work\Catalina\localhost\drp5.9\org\apache\jsp\login_jsp.java]
The methodgetJspApplicationContext(ServletContext) is undefined for the type JspFactory
 
Stacktrace:
atorg.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:103)
atorg.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:366)
atorg.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:476)
atorg.apache.jasper.compiler.Compiler.compile(Compiler.java:378)
atorg.apache.jasper.compiler.Compiler.compile(Compiler.java:353)
atorg.apache.jasper.compiler.Compiler.compile(Compiler.java:340)
atorg.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:657)
atorg.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
atorg.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
atorg.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
atjavax.servlet.http.HttpServlet.service(HttpServlet.java:727)
atorg.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
atorg.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
atorg.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
atorg.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
atorg.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
atcom.bjpowernode.drp.util.filter.CharsetEncodingFilter.doFilter(CharsetEncodingFilter.java:40)
atorg.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
atorg.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
atorg.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
atorg.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
atorg.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
atorg.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
atorg.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
atorg.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
atorg.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
atorg.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
atorg.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1070)
atorg.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
atorg.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2440)
atorg.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2429)
atjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
atjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
atorg.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
atjava.lang.Thread.run(Thread.java:744)

 

于是仅仅好去网上查资料。有好多人都说是JSP页面代码编写错误或者说是Java环境变量没有配置好导致的。因为我之前JSP页面能够正常执行。全部就将这个说法给排除了。

 

 

接着找网上说的是Tomcat文件夹下的conf文件夹里的web.xml文件与项目中的web.xml文件的版本号标识不一样，于是就将Tomcat里的web.xml文件改成了和项目里的一样的标识版本号。

就是以下这句话：

<?xmlversion="1.0" encoding="UTF-8"?

> <web-appversion="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> <display-name></display-name> </web-app>

 

然后又一次启动项目的JSP页面，错误继续存在。于是在网上继续找，发现网上非常多的人又说是由于项目中有比較低的版本号的jar包导致的：以下是网上的原话。非常多人都允许以下这样的说法。

 

“catalina.jar、jsp-api.jar、servlet-api.jar、javax.servlet.jar、javax.servlet.jsp.jar等包和应用server（JBoss/Tomcat等）中的包反复且比其版本号低。应用server在启动时会优先载入项目中的包，这样就导致和应用server中的其他包不匹配。

可把反复的包从项目中删除。或将应用server下的这些包复制到项目中，重新启动服务就可以。”

 

接下来我真的在 javaee Library中发现了javax.servlet.jar 和javax.servlet.jsp.jar jar两个包

。于是就将它们移除了。当再次启动JSP页面时这个问题依旧存在。

 

到这里，好几个小时都已经过去。心情有点小浮躁了已经。强迫让自己冷静下来，好好将这个问题顺一顺。

 

因为之前JSP页面能够正常执行。排除JSP代码编写错误，唯一做的改变也仅仅是又一次换了一个Tomcat而已，Tomcat换完以后，环境变量也已经配置完毕了。不可能是环境变量的问题。

如今页面不能正常执行。会不会是因为之前的64位Tomcat的jar包影响了如今32位的Tomcat。于是接下来做了一个试验，又一次建立一个项目，在里面建立一个新的JSP页面，能够正常訪问。

 

最后问题攻克了，解决方法非常搞笑：新建立一个项目，将原来项目的类、配置文件、jsp文件、还有我们自己专门引入的jar包，也就是自己在做项目中加入或引入的文件复制到新建立的项目中。然后执行就成功了，问题就不会再出现了。

 

 

果然是之前的64位Tomcat的jar包影响的。尽管之前的64位的Tomcat早已经移除了，但是之前的64位的Tomcat的一些jar包仍然包括在项目中导致的。

 

尽管过程一波三折。只是终于问题还是攻克了。

 

转载于:https://www.cnblogs.com/yxysuanfa/p/6749628.html