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包仍然包括在项目中导致的。
尽管过程一波三折。只是终于问题还是攻克了。
