tomcat如何生成其工作目录*_jsp.java文件，以及什么可能导致它生成零字节文件？
我的问题源自从 Tomcat 6.0.18 升级到 7.0.22，尽管其他版本似乎也可能出现该问题。我怀疑这源于我对 Tomcat 核心行为的误解，尽管在搜索了 Tomcat 之后文档，之前关于 Tomcat 的 SO 问题（太多而无法有效引用），以及来自不同来源的各种博客文章（同样不够切题，值得引用），我不知所措。
我正在使用的应用程序是一个庞大的 java 应用程序，包含数百个 JSP 页面。过去，在 Tomcat 6 上，我们在运行时编译它们没有遇到任何问题。它们（大部分）在 Tomcat 的工作目录中正确生成 *_jsp.java 文件，并且编译为 *.class 文件按预期工作。那些没有的代码是在生产设置中未使用的遗留代码，但由于不值得在此处指定的原因，它们仍在代码库中。
当迁移到 Tomcat 7（特别是 7.0.22）时，我遇到了意外的行为。绝大多数 JSP 页面都可以编译到工作目录中（无论是 .java 代码还是其附属的 .class 文件）。然而，有些会生成 0 字节的 .java 文件。
我对这个问题的第一反应是：“除了 JSP 规范本身之外，两个版本之间有关 Tomcat JSP 编译的某些内容发生了变化。”在浏览了文档后，似乎没有什么明显的，所以我尝试预编译所有jsps使用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 以及 Tomcat 编译到工作目录时出现问题的 0 字节文件都用此方法正确编译。与 Tomcat 6 的工作目录 *_jsp.java 文件相比，存在一些细微差别，但它们似乎可能与 JSP规范版本6到7之间升级。不幸的是，我们的遗留代码使得一些生成的 .java 文件通常在两个版本中都无法编译。让它们从 .java 编译为 .class （而不是 .jsp 到 *_jsp.java 到 < code>*_jsp.class) 需要深度重构。因此，我无法追求真正的 JSP 预编译策略。 Tomcat 似乎比我的脚本更智能地处理这些文件，这并不奇怪。
那么，我的问题有点广泛：什么可能导致 tomcat 在其工作目录中生成空的 *_jsp.java 文件？作为推论，Tomcat 通过什么过程在其工作目录中生成这些文件，这与我使用 Ant 脚本生成这些文件的方式有何不同？我怀疑对 Tomcat 核心行为的更深入理解可能会产生一个明显的解决方案、一个可解释的问题，或者至少是一个像“这是设计好的。请重构”这样的答案。
My question derives from an upgrade from Tomcat 6.0.18 to 7.0.22, although it seems likely the issue arises in other versions. I suspect it stems from my misunderstanding of Tomcat's core behavior, although after a search of the Tomcat documentation, previous SO questions about Tomcat (too numerous to effectively cite), and a variety of blog posts from various sources (again not on-topic enough to be worth citing), I'm at a loss.
The application I'm working with is a sprawling java app with hundreds of JSP pages. In the past, on Tomcat 6, we've had no trouble compiling them at runtime. They (for the most part) correctly generate *_jsp.java files within Tomcat's work directory, and the compilation to *.class files works as expected. Those that don't are legacy code that is unused in production settings, still in the codebase for reasons not worth specifying here.
When moving to Tomcat 7, specifically 7.0.22, I encountered unexpected behavior. The vast majority of the JSP pages compile (both to .java code and to their affiliated .class files) just fine into the work directory. Some, however, generate 0-byte .java files.
My first take at this problem was: "Something about Tomcat JSP compilation changed between the two versions, other then the JSP specification itself." After poking around in the docs, nothing seemed obvious, so I attempted to pre-compile all the jsps using Ant.
This succeeded insofar as the conversion to .java files was concerned, using an extremely simple ant script:
<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 files were correctly generated by jasper, and the 0-byte files that caused trouble when compiled by Tomcat into the work directory were compiling properly with this method. There were a few minor differences when compared with Tomcat 6's work directory *_jsp.java files, but they seem likely related to the JSP spec version upgrade between 6 and 7. Unfortunately, our legacy code makes some of the resulting .java files uncompilable, generally, in both versions. Making them compile from .java to .class (as opposed to .jsp to *_jsp.java to *_jsp.class) would require a deep refactor. Thus, I'm unable to pursue a true JSP pre-compilation strategy. Tomcat appears to handle these files more intelligently then my scripts, which isn't at all surprising.
My question, then, is a bit broader: What might cause tomcat to generate empty *_jsp.java files in its work directory? As a corollary, by what process does Tomcat generate those files in its work directory, and how does that differ from the way I might generate those files with an Ant script? I suspect a deeper understanding of Tomcat's core behavior might yield an obvious solution, an explainable problem, or at least an answer like "This is designed. Please refactor."
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们遇到了类似的问题，并在我们的上下文中找到了原因：一旦tomcat启动，我们就在持续集成环境中运行selenium测试，因此部署尚未完成，并且以某种方式产生了0长度（空）*jsp。 java 和 *jsp.class 文件。
有趣的是，所有构建都会发生这种情况，因为部署总是比开始运行测试花费的时间更长（大约 1m）。
我们通过引入延迟来修复此问题，以允许内部 tomcat 部署程序完成其工作。
We had a similar problem and found the cause in our context: we were running a selenium test in our continuous integration environment as soon as tomcat started, so deployment had not completed yet, and that somehow produced the 0 length (empty) *jsp.java and *jsp.class files.
The interesting thing is that this happened for all builds, because deployment always took longer (around 1m) than what it took start running the tests.
We fixed it by introducing a delay to allow the internal tomcat deployer to complete its work.