tomcatはどのように作業ディレクトリー* _jsp.javaファイルを生成するのですか？何が原因でゼロバイトのファイルが生成されるのですか？

Question

私の質問は、Tomcat 6.0.18から7.0.22へのアップグレードに由来しますが、他のバージョンで問題が起きそうです。私はそれがTomcat documentationを検索した後、Tomcatについての以前の質問（効果的に引用するには数が多すぎます）と様々なソースからのさまざまなブログ記事（これは、引用する価値がある）、私は迷っています。

私が扱っているアプリケーションは、何百ものJSPページを含む大規模なJavaアプリケーションです。これまでTomcat 6では、実行時にコンパイルするのに問題はありませんでした。彼らは（ほとんどの場合）正確に*_jsp.javaファイルをTomcatの作業ディレクトリ内に生成し、* .classファイルへのコンパイルは期待通りに機能します。プロダクション設定で使用されていないレガシーコードではなく、ここで指定する価値がないためコードベースに残っています。

Tomcat 7、特に7.0.22に移動すると、予期しない動作が発生しました。大多数のJSPページは、作業ディレクトリに正確にコンパイルされます（.javaコードとその関連する.classファイル）。ただし、一部のファイルでは0バイトの.javaファイルが生成されます。

この問題で私が最初に取ったのは、「TomcatのJSPコンパイルに関することが、2つのバージョン間で変更されました。 in the docsを突き止めた後、何も明らかに見えなかったので、私はattempted to pre-compile all the jsps using Antです。

は、これは非常に簡単なAntスクリプトを使用して、心配していた.javaファイルへの変換限りにおいて成功：

<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の中核的な振る舞いをより深く理解することで、明白な解決策、説明可能な問題、または少なくとも「これは設計されています。リファクタリングしてください。

Answer 1

私たちは、Tomcatが始動するとすぐに継続的な統合環境でセレンテストを実行していたため、展開がまだ完了せず、何とか0の長さが空になりました）* jsp.javaおよび* jsp.classファイル。 興味深いことに、これはすべてのビルドで起こったことです。なぜなら、デプロイメントは、テストの実行を開始するよりも（約1m）時間がかかっていたからです。

遅延を導入して、内部のTomcatデプロイヤがその作業を完了できるように修正しました。