Webからxml開始
10629 ワード
時々戸惑うxmlはいったい何ですか.なぜJavaEEはwebからxmlは始まりますか?ええと、このフレームワークを捨てると、いくつかの基礎的な問題がとても面白いです.
web.xmlは必須ではありません.同じようにwebプログラムを書く必要はありません.
web.xmlファイルはwelcome、listener、servlet、filterなどを構成するために使用されます.Webプロジェクトがこれらを使用していない場合は、Webを書かなくてもいいです.xmlファイル.
本題に入る.
SpringはサーブレットContextListenerの実装クラスContextLoaderListenerを提供し、このクラスはlistenerとして使用することができ、作成時に自動的にWEB-INF/下のアプリケーションContextを検索する.xrnlファイル.
Springプロファイルが複数ある場合はcontext-paramを使用することを考慮します.
ContextLoaderListenerがロードされるとcontextConfigLocationという名前のパラメータが検索されるため、context-paramを構成するときのパラメータ名はcontextConfigLocationである必要があります.
Spring MVCのサーブレットは、WEB-INF/123 web-servletをロードします.xmlのプロファイルでSpring MVCモジュールを起動します.
session-timeout要素は、デフォルトのセッションタイムアウト間隔を分単位で指定します.この要素の値は整数でなければなりません.セッション-timeout要素の値がゼロまたは負の場合、セッションはタイムアウトしません.
404およびwelcomeページ:
Webについてxmlの興味深い詳細:
@ロード順
ロード順序はwebにあります.xmlファイルの優先順位は関係ありません.すなわち、filterがlistenerの前に書かれているため、filterが先にロードされることはありません.最終的に、listener->filter->servletという構成セクションが存在し、サーブレットContextにキー値ペア、すなわちアプリケーションコンテキスト情報を提供するためのcontext-paramという構成セクションも存在する.私たちのlistener、filterなどは初期化時にこれらのコンテキストの情報を使用しますが、context-param構成セクションはlistener構成セクションの前に書くべきではないでしょうか.実際にはcontext-param構成セクションは任意の場所に書くことができるので、実際のロード順序はcontext-param->listener->filter->servletです.
@Mappingルール
リクエストがservletコンテナに送信されると、コンテナはまずリクエストされたurlから現在のアプリケーションコンテキストのパスをservletのマッピングurlとして減算します.たとえば、私がアクセスしたのはhttp://localhost/test/aaa.htmlああ、私のアプリケーションコンテキストはtestで、コンテナはhttp://localhost/test削除、残り/aaa.html部分はservletのマッピングマッチングをします.このマッピングマッチングプロセスには順序があり、servletマッチングが成功すると、残りのservletは無視されません(filterは異なり、後述します).一致する規則と順序は次のとおりです.
1.正確なパスマッチング.例:例えばservletaのurl-patternは/test、servletBのurl-patternは/*であり、この場合、私がアクセスしたurlがhttp://localhost/testああ、このとき容器はまず正確な経路マッチングを行い、/testがちょうどservletaによって正確にマッチングされていることを発見したら、servletaを呼び出しても、他のservletを気にすることはありません.
2.最長パス一致.例:servletaのurl-patternは/test/*であり、servletBのurl-patternは/test/a/*であり、このときアクセスするhttp://localhost/test/aを選択すると、コンテナはパスが最も長いservletを選択して一致します.つまり、ここのservletBです.
3.拡張マッチング.urlの最後のセグメントに拡張が含まれている場合、コンテナは拡張に基づいて適切なservletを選択します.例:servletaのurl-pattern:*.action
@異なるマッピング
パスマッピングには、"/'で始まり、"/*"で終わります.
接頭辞で最初は拡張マッピングに使用されます.
したがって、なぜ定義するのか」/*Action」という正常に見えるマッチングは間違っていますか?このマッチングはパスマッピングにも拡張マッピングにも属するため,コンテナは判断できない.
web.xmlは必須ではありません.同じようにwebプログラムを書く必要はありません.
web.xmlファイルはwelcome、listener、servlet、filterなどを構成するために使用されます.Webプロジェクトがこれらを使用していない場合は、Webを書かなくてもいいです.xmlファイル.
本題に入る.
SpringはサーブレットContextListenerの実装クラスContextLoaderListenerを提供し、このクラスはlistenerとして使用することができ、作成時に自動的にWEB-INF/下のアプリケーションContextを検索する.xrnlファイル.
<
listener
>
<
listener-class
>
org.springframework.web.context.ContextLoaderListener
</
listener-class
>
</
listener
>
Springプロファイルが複数ある場合はcontext-paramを使用することを考慮します.
ContextLoaderListenerがロードされるとcontextConfigLocationという名前のパラメータが検索されるため、context-paramを構成するときのパラメータ名はcontextConfigLocationである必要があります.
<
context-param
>
<
param-name
>
contextConfigLocation
</
param-name
>
<
param-value
>
classpath:applicationContext.xml
</
param-value
>
</
context-param
>
Spring MVCのサーブレットは、WEB-INF/123 web-servletをロードします.xmlのプロファイルでSpring MVCモジュールを起動します.
<
servlet
>
<
servlet-name
>
123web
</
servlet-name
>
<
servlet-class
>
org.springframework.web.servlet.DispatcherServlet
</
servlet-class
>
<
load-on-startup
>
2
</
load-on-startup
>
</
servlet
>
<
servlet-mapping
>
<
servlet-name
>
123web
</
servlet-name
>
<
url-pattern
>
*.do
</
url-pattern
>
</
servlet-mapping
>
session-timeout要素は、デフォルトのセッションタイムアウト間隔を分単位で指定します.この要素の値は整数でなければなりません.セッション-timeout要素の値がゼロまたは負の場合、セッションはタイムアウトしません.
<
session-config
>
<
session-timeout
>
30
</
session-timeout
>
</
session-config
>
404およびwelcomeページ:
<
welcome-file-list
>
<
welcome-file
>
index.do
</
welcome-file
>
</
welcome-file-list
>
<
error-page
>
<
error-code
>
404
</
error-code
>
<
location
>
/404.jsp
</
location
>
</
error-page
>
Webについてxmlの興味深い詳細:
@ロード順
ロード順序はwebにあります.xmlファイルの優先順位は関係ありません.すなわち、filterがlistenerの前に書かれているため、filterが先にロードされることはありません.最終的に、listener->filter->servletという構成セクションが存在し、サーブレットContextにキー値ペア、すなわちアプリケーションコンテキスト情報を提供するためのcontext-paramという構成セクションも存在する.私たちのlistener、filterなどは初期化時にこれらのコンテキストの情報を使用しますが、context-param構成セクションはlistener構成セクションの前に書くべきではないでしょうか.実際にはcontext-param構成セクションは任意の場所に書くことができるので、実際のロード順序はcontext-param->listener->filter->servletです.
@Mappingルール
リクエストがservletコンテナに送信されると、コンテナはまずリクエストされたurlから現在のアプリケーションコンテキストのパスをservletのマッピングurlとして減算します.たとえば、私がアクセスしたのはhttp://localhost/test/aaa.htmlああ、私のアプリケーションコンテキストはtestで、コンテナはhttp://localhost/test削除、残り/aaa.html部分はservletのマッピングマッチングをします.このマッピングマッチングプロセスには順序があり、servletマッチングが成功すると、残りのservletは無視されません(filterは異なり、後述します).一致する規則と順序は次のとおりです.
1.正確なパスマッチング.例:例えばservletaのurl-patternは/test、servletBのurl-patternは/*であり、この場合、私がアクセスしたurlがhttp://localhost/testああ、このとき容器はまず正確な経路マッチングを行い、/testがちょうどservletaによって正確にマッチングされていることを発見したら、servletaを呼び出しても、他のservletを気にすることはありません.
2.最長パス一致.例:servletaのurl-patternは/test/*であり、servletBのurl-patternは/test/a/*であり、このときアクセスするhttp://localhost/test/aを選択すると、コンテナはパスが最も長いservletを選択して一致します.つまり、ここのservletBです.
3.拡張マッチング.urlの最後のセグメントに拡張が含まれている場合、コンテナは拡張に基づいて適切なservletを選択します.例:servletaのurl-pattern:*.action
@異なるマッピング
パスマッピングには、"/'で始まり、"/*"で終わります.
接頭辞で最初は拡張マッピングに使用されます.
したがって、なぜ定義するのか」/*Action」という正常に見えるマッチングは間違っていますか?このマッチングはパスマッピングにも拡張マッピングにも属するため,コンテナは判断できない.