2012-01-11 25 views
0

我的问题来自Tomcat 6.0.18升级到7.0.22,尽管在其他版本中可能会出现这个问题。我猜想这是因为我误解了Tomcat的核心行为,尽管在搜索了Tomcat documentation之后,之前关于Tomcat的SO问题(太多无法有效引用)以及来自各种来源的各种博客帖子(再次没有讨论足够的话题值得引用),我很茫然。tomcat如何生成其工作目录* _jsp.java文件,以及可能导致它生成零字节的文件?

我正在使用的应用程序是一个具有数百个JSP页面的庞大的Java应用程序。过去,在Tomcat 6上,我们在运行时编译它们毫无困难。他们(大部分)在Tomcat的工作目录中正确生成*_jsp.java文件,并且编译为* .class文件的工作正如预期的那样。那些不是在生产设置中未使用的遗留代码,仍然在代码库中,原因不值得在此指定。

当移动到Tomcat 7,特别是7.0.22时,我遇到了意外的行为。绝大多数JSP页面都可以编译到(.java代码及其附属的.class文件),并且很好地嵌入到工作目录中。但是,有些文件会生成0字节的.java文件。

我先来这个问题是:“关于Tomcat的JSP编译东西两个版本之间的变化,其他则JSP规范本身。”拨打in the docs后,似乎没有什么明显的,所以我attempted to pre-compile all the jsps using Ant

这只要成功为.java文件中涉及的转换,用一个非常简单的ant脚本:

<project name="myApp" default="all" basedir="."> 
    <import file="${tomcat.home}/bin/catalina-tasks.xml"/> 
    <target name="jspc"> 
     <jasper 
      validateXml="false" 
      uriroot="${webapp.home}" 
      webXmlFragment="${webapp.home}/WEB-INF/generated_web.xml" 
      outputDir="${webapp.home}/WEB-INF/classes" 
      failonerror="false" /> 
    </target> 
    <target name="all" depends="jspc"> 
    </target> 
</project> 

*_jsp.java文件被正确地jasper生成,编译时造成麻烦的0字节文件通过Tomcat进入工作目录,用这种方法正确编译。与Tomcat 6的工作目录*_jsp.java文件相比,有一些细微差异,但它们似乎与JSP spec version upgrade between 6 and 7有关。不幸的是,我们的遗留代码通常在两个版本中都使得一些.java文件无法编译。使他们从编译到.java.class(相对于.jsp*_jsp.java*_jsp.class)将需要深重构。因此,我无法追求真正的JSP预编译策略。 Tomcat似乎更聪明地处理这些文件,然后是我的脚本,这并不令人意外。

我的问题,那么,确实有点更广:什么可能导致Tomcat能够产生在其工作目录空*_jsp.java文件?作为推论,Tomcat通过什么过程在其工作目录中生成这些文件,以及这与我可能使用Ant脚本生成这些文件的方式有何不同?我怀疑对Tomcat核心行为的更深入的理解可能会产生一个明显的解决方案,一个可解释的问题,或者至少是“这是设计的,请重构”的答案。

+0

我不知道0字节的文件,但如果遗留的非编译JSP未使用,为什么不删除它们。如果它们被使用了,为什么不修复它们? – 2012-01-11 07:16:32

+0

其中一些是我正在努力删除的未使用的遗留文件。其他人比较老[JSP不遵循最佳实践](http://stackoverflow.com/a/3180202/877115)。我很想修复这些麻烦的代码,因为预编译似乎是出于性能原因的一个好主意,但不幸的是,重构对于我的组织来说是不起作用的。 – Christopher 2012-01-11 15:19:46

+0

他们编译还是不编译?如果他们不编译,他们不需要重构:他们需要被修复或删除。如果它们不通过预编译进行编译,那么也不会在Tomcat中进行编译。 – 2012-01-11 15:27:07

回答

0

我们有类似的问题,并在我们的上下文中找到了原因:一旦tomcat启动,我们在持续集成环境中运行硒测试,因此部署尚未完成,并以某种方式产生了0长度)* jsp.java和* jsp.class文件。 有趣的是,这发生在所有构建中,因为部署总是比开始运行测试花费的时间更长(约1米)。

我们通过引入一个延迟来解决它,允许内部tomcat部署者完成其工作。