0

GWT-Spring プロジェクトがあり、Web プロジェクトでライブラリとして使用される 2 つのモジュールもあります。すべて正常に動作しますが、それらのモジュール (JAR) の 1 つにいくつかの静的リソースを配置しようとしていますが、アプリケーションのデプロイ時にリソースが表示されないため、取得しようとすると 404 が返されます。

web.xml で Servlet 3.0 を使用しており、この行を application-config に追加します。

<mvc:resources mapping="/resources/**"  location="classpath:/META-INF/resources" ></mvc:resources>

また、すべてのリソースを JAR 内の META-INF/resources フォルダーの下に置きました。

http://localhost:8888/path/resourcesにアクセスすると、Jetty (IntelliJ) を使用してプロジェクトを実行します。これらのフォルダーのリスト全体を確認できます (META-INF/resources JAR に配置したすべてのフォルダーとリソースWeb プロジェクトですが、JAR についてはフォルダーのみが表示され、フォルダー上のファイルは表示されません! )

プロジェクトを tomcat で実行すると、Web プロジェクトのリソースのみが表示され、JAR のリソースはすべて表示されます。

何か案は？

4

2 に答える 2

1

/META-INF/resources/にあるfrom jarの提供は/WEB-INF/lib/*.jar、Servlet 3.0 仕様の機能です。

そのため、Jetty の内部実装 (つまり、そのDefaultServlet) は、このコンテンツの要求に対してこのコンテンツを返す責任があります。

Jetty では、/META-INF/resources/コンテンツを WebApp 作業ディレクトリにアンパックして、ディスクから通常のファイルとして提供することでこれを実現します。

ただし、Spring MVC を使用しており、構成がコンテナのこの機能を回避しようとしているようです。Spring MVC にそれらのリソースを処理または提供させず、Spring から流出させ、Web コンテナー自体にそれらのリソースを提供させます。

さらに、Jetty の実装は、これらの (そして実際にはあらゆる種類の) 静的リソースを、一般的なサーブレットよりもはるかに優れた方法で提供できます (これを実現するために Jetty の内部機能を使用します)。

例：

単一の resource を含む があったfoo.warとしましょう。/WEB-INF/lib/bar.jar/META-INF/resources/js/main.js

のコネクタを備えた Jetty サーバーがあり、localhost:8080デフォルトの webapp Deployment があり、その結果、 のコンテキスト パスが であると仮定/fooするとfoo.war、このリソースには、への要求でアクセスできます。http://localhost:8080/foo/js/main.js

これを示すサンプル プロジェクトを次の場所に作成しました。

github.com/jetty-project/jetty-example-metainf-resources

于 2015-09-25T20:16:42.827 に答える
0

問題が見つかりました。

これは単にセキュリティ上の問題でした。URL が保護されていれば、セッションが開始されていない場合でもリソースを利用できます。

さらに、 内のリソースはWEB-INF/lib/*.jar!/META-INF/resources 別の "resources" フォルダーでは公開されず、ルートで直接公開されます。

ありがとう。

于 2015-09-28T14:21:22.680 に答える