Springで静的リソースを提供する
1. 概要
この記事では、XMLとJavaの両方の構成を使用してserve static resources with Springを実行する方法について説明します。
参考文献:
Spring MVCを使用したキャッシュ可能な静的アセット
この記事では、Spring MVCを使用してJavascriptやCSSファイルなどの静的アセットを提供する際のキャッシュ方法について説明します。
2. XML構成
XMLベースの構成で昔ながらの方法を採用する必要がある場合は、mvc:resources要素をうまく利用して、特定のパブリックURLパターンを持つリソースの場所を指すことができます。
たとえば、次の行は、アプリケーションのルートフォルダの下にある「/resources/」ディレクトリを検索することにより、「/resources/**」のようなパブリックURLパターンで受信するリソースに対するすべてのリクエストを処理します。
これで、次のhtmlページのようにCSSファイルにアクセスできます。
例2.1
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
" rel="stylesheet">
Home
Hello world!
3. ResourceHttpRequestHandler
Spring 3.1.は、クラスパス、WAR、またはファイルシステムから静的リソースを提供するためにResourceHttpRequestHandlersを構成するためにResourceHandlerRegistryを導入しました。 Webコンテキスト構成クラス内でプログラムによってResourceHandlerRegistryを構成できます。
3.1. WARに保存されているリソースを提供する
これを説明するために、以前と同じURLを使用してmyCss.cssをポイントしますが、実際のファイルはWARのwebapp/resourcesフォルダーに配置されます。このフォルダーには、デプロイ時に静的リソースを配置する必要があります。 Spring 3.1以降のアプリケーション:
例3.1.1。
@Configuration
@EnableWebMvc
public class MvcConfig implements WebMvcConfigurer {
@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
registry
.addResourceHandler("/resources/**")
.addResourceLocations("/resources/");
}
}
サンプルビットを分析してみましょう。 最初に、リソースハンドラーの定義を追加して、外部向けURIパスを構成します。 次に、外部に面するURIパスを、リソースが実際に配置されている物理パスに内部的にマッピングします。
もちろん、このシンプルかつ柔軟なAPIを使用して、複数のリソースハンドラーを定義できます。
さて、htmlページの次の行は、webapp/resourcesディレクトリ内のmyCss.cssリソースを取得します。
" rel="stylesheet">
3.2. ファイルシステムに保存されているリソースを提供する
パターン/files/**に一致するパブリックURLの要求が来るたびに、/opt/files/ディレクトリに格納されているリソースを提供するとします。 URLパターンを構成し、ディスク上の特定の場所にマップするだけです。
例3.2.1。
@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
registry
.addResourceHandler("/files/**")
.addResourceLocations("file:/opt/files/");
}
*(Windowsユーザーの場合:この例でaddResourceLocationsに渡される引数は「file:///C:/opt/files/」になります)。
リソースの場所を構成したら、次のようにhome.htmlからload an image stored in the file systemにマップされたURLパターンを使用できます。
例3.2.2。
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
" rel="stylesheet">
Home
Hello world!
">
3.3. リソースの複数の場所の構成
複数の場所でリソースを検索する場合はどうなりますか?
addResourceLocationsメソッドを使用して複数の場所を含めることができます。 場所のリストは、リソースが見つかるまで順番に検索されます。 例3.3.1を見てみましょう。
例3.3.1
@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
registry
.addResourceHandler("/resources/**")
.addResourceLocations("/resources/","classpath:/other-resources/");
}
次のcurlリクエストは、クラスパスのアプリケーションのwebappp/resourcesまたはother-resourcesフォルダに保存されているHello.htmlページを表示します。
curl -i http://localhost:8080/handling-spring-static-resources/resources/Hello.html
4. 新しいResourceResolvers
春4.1。 新しいResourcesResolversで、静的リソースをロードするときにブラウザーのパフォーマンスを最適化するために使用できるさまざまなタイプのリソースリゾルバーを提供します。 これらのリゾルバは、リクエスト処理を最適化するために、ブラウザでチェーン化およびキャッシュできます。
4.1. PathResourceResolver
これは最も単純なリゾルバであり、その目的は、パブリックURLパターンが指定されたリソースを見つけることです。 実際、ResourceResolverがResourceChainRegistrationに追加されていない場合、これがデフォルトのリゾルバーです。
例を見てみましょう:
@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
registry
.addResourceHandler("/resources/**")
.addResourceLocations("/resources/","/other-resources/")
.setCachePeriod(3600)
.resourceChain(true)
.addResolver(new PathResourceResolver());
}
気をつけるべきこと:
-
リソースチェーン内のPathResourceResolverを唯一のResourceResolverとして登録しています。 セクション4.3を参照してください。 複数のResourceResolverをチェーンする方法を確認します。
-
提供されるリソースは、3600秒間ブラウザにキャッシュされます。
-
チェーンは最終的にメソッドresourceChain(true)で構成されます。
今–PathResourceResolverと組み合わせて、webapp/other-resourcesフォルダーのwebapp/resourcesのいずれかにfoo.jsスクリプトを配置するhtmlコード:
">
4.2. EncodedResourceResolver
このリゾルバーは、Accept-Encoding要求ヘッダー値に基づいてエンコードされたリソースを見つけようとします。
たとえば、gzipコンテンツコーディングを使用して静的リソースの圧縮バージョンを提供することにより、帯域幅を最適化する必要がある場合があります。
EncodedResourceResolver,を構成するには、次のコード行のように、PathResourceResolverを構成したのと同じように、ResourceChainで構成する必要があります。
registry
.addResourceHandler("/other-files/**")
.addResourceLocations("file:/Users/Me/")
.setCachePeriod(3600)
.resourceChain(true)
.addResolver(new EncodedResourceResolver());
デフォルトでは、EncodedResourceResolverはbrおよびgzipコーディングをサポートするように構成されています。
したがって、次のcurl要求は、Users/Me/ディレクトリのファイルシステムにあるHome.htmlファイルのzipバージョンを取得します。
curl -H "Accept-Encoding:gzip"
http://localhost:8080/handling-spring-static-resources/other-files/Hello.html
we are setting the header’s “Accept-Encoding” value to gzipに注意してください。この特定のリゾルバーは、gzipコンテンツが応答に対して有効である場合にのみ起動するため、これは重要です。
最後に、以前と同じように、圧縮されたバージョンはブラウザにキャッシュされている間、この場合は3600秒使用可能です。
4.3. チェーンResourceResolvers
リソースルックアップを最適化するために、ResourceResolversはリソースの処理を他のリゾルバーに委任できます。 チェーンに委任できない唯一のリゾルバーは、チェーンの最後に追加する必要があるPathResourceResolverです。
実際、resourceChainがtrueに設定されていない場合、デフォルトでは、PathResourceResolverのみがリソースの提供に使用されます。 例4.3.1で。 GzipResourceResolverが失敗した場合は、リソースを解決するためにPathResourceResolverをチェーンします。
例4.3.1。
@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
registry
.addResourceHandler("/js/**")
.addResourceLocations("/js/")
.setCachePeriod(3600)
.resourceChain(true)
.addResolver(new GzipResourceResolver())
.addResolver(new PathResourceResolver());
}
/js/**パターンをResourceHandlerに追加したので、例4.3のように、home.htmlページのwebapp/js/ディレクトリにあるfoo.jsリソースを含めます。 .2。
例4.3.2。
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
" rel="stylesheet" />
">
Home
This is Home!
" />
5. 追加のセキュリティ構成
Spring Securityを使用している場合–静的リソースへのアクセスを許可することが重要です。 リソースURLにアクセスするための対応する権限を追加する必要があります。
6. 結論
この記事では、Springアプリケーションで静的リソースを提供するさまざまな方法を説明しました。
XMLベースのリソース構成はa “legacy” optionであり、Java構成ルートをまだたどることができない場合に使用できます。
Spring 3.1. came out withは、そのResourceHandlerRegistryオブジェクトを介した基本的なプログラムの代替手段です。
そして最後に–新しい箱から出してすぐに使えるResourceResolversとResourceChainRegistrationオブジェクトshipped with Spring 4.1。 キャッシングやリソースハンドラチェーンなどのリソースロード最適化機能を提供して、静的リソースの提供効率を改善します。
いつものように、完全な例は利用可能なover on Githubです。