0

jetty-6.1.9.jar、jsp-2.1.jar、jsp-api-2.1.jar、servlet-api-2.5-6.1.9.jarを含み、JRE1.7.0_03で実行されているレガシープロジェクトを使用しています。 。

JettyサーバーはMyServer.javaのmainメソッド内で起動されます。WebAppContextを作成し、WebAppContext.setWar（$ webAppRoot）を呼び出します。ここで、$ webAppRootは、通常のWEB-INF構造であるディレクトリへのフルパスです。

すべてのアプリクラスと依存JARは、MyServer.mainを呼び出すクラスパスで指定されます。WEB-INF/ libにはJARはなく、WEB-INF / classにはクラスはありません（そうです、混乱していることはわかっています）。html、javascript、css、JSPファイルは$webAppRootにあります。

JSP2.1のサポートについて話しているJettyのドキュメントは、ant-1.6.5が必須の依存関係であることを示しています。このプロジェクトにはantは含まれていませんが、JSPはコンパイルされ、ヒットすると機能します。

アプリケーションクラスファイルをWEB-INF/classesに移動し、それらに依存するJARをWEB-INF / libに移動すると、JSPの1つにヒットしたときに、ANT関連のクラスが見つからないというエラーがJettyによってスローされます。元の構成でANTなしでJSPをコンパイルするのに、WEB-INFに移動するとANTが必要になるのはなぜですか？

4

1 に答える 1

2

それらのjsp jarはどこで入手していますか？

JSP は、キッチンの引き出しよりも多くのフォークを備えたクレイジーなテクノロジです...私たちが消費するもの (jsp.java.net のもの) が死んでいるように見え、on で更新を取得するための合理的なパスが必要であるため、私は最近、フォークすることを提唱しました。 jetty への IP 許容 jsp。とにかく、余談ですが、現在 jetty 7、8、および 9 にある jsp バージョンでは、デフォルトの動作はシステム コンパイラを使用することであり、特定のプロパティが設定されている場合 (org.apache.jasper.compiler.disablejsr199=true)、それは代わりに、現在配布している eclipse コンパイラか、その後の ant のいずれかを探します。したがって...この動作は、使用しているjsp実装に完全に依存しています。クラスパスに ant がなく、jsps がコンパイルされている場合は、システム コンパイラによって実行されている可能性があります。

また、レガシー プロジェクトで作業していることは承知していますが、サポートされている最新バージョンの jetty に更新することを強くお勧めします。そして、6.1.9 と最後のメンテナンス リリースの間に多くのことが修正されたため、jetty 6.1.26 に更新することをお勧めします。それを除いて、jsp の問題がある場合は、6.1.26 ディストリビューションから jsp jar だけを更新すると、問題が解決する可能性があります。それらのjsp jarのソースをクラックして開く必要があるかもしれません（これはmaven centralのorg/mortbay/jettyの下にあると思います）。

最後に、jetty 6 に触れてから数年が経ちましたが、おそらく ant を webapp クラスローダに入れる必要がありますが、それはシステム クラスローダにあったため、以前は機能していましたか? $jetty.home/lib の下にある場合、おそらく webapp コンテキストは、webapp クラスローダーで親の優先順位を使用するように構成され、そこから ant をプルしましたか?

[編集] 6.1.9 用の maven-jetty-jspc-plugin があることに気付きました。そのため、jsps をプリコンパイルするだけで作業を完了することができます。( http://repo2.maven.org/maven2/org/mortbay/jetty/maven-jetty-jspc-plugin/ )

于 2013-03-08T19:47:44.280 に答える