Java EE Webアプリケーションで使用されるWEB-INFは何ですか？

私は、次のソースコード構造を持つJava EE Webアプリケーションに取り組んでいます。

src/main/java                 <-- multiple packages containing java classes
src/test/java                 <-- multiple packages containing JUnit tests
src/main/resources            <-- includes properties files for textual messages
src/main/webapp/resources     <-- includes CSS, images and all Javascript files
src/main/webapp/WEB-INF
src/main/webapp/WEB-INF/tags
src/main/webapp/WEB-INF/views

私が興味を持ってWEB-INFいるのはweb.xml、サーブレットを設定するためのXMLファイル、Spring Beanのワイヤリングコンテキスト、JSPタグとビューが含まれていることです。

私はこの構造を制約/定義するものを理解しようとしています。たとえば、JSPファイルは常にその中にあるWEB-INF必要がありますか、それとも他の場所にある可能性がありますか？そして、他に入る可能性があるものはありWEB-INFますか？WikipediaのWARファイルエントリにはclasses、JavaクラスとlibJARファイルに関する記述があります。他のソースファイルの場所に加えて、これらが必要になる時期を十分に理解していません。

サーブレット2.4仕様では、 WEB-INF（70ページ）については、これを言います：

という名前のアプリケーション階層内に特別なディレクトリが存在します WEB-INF。このディレクトリには、アプリケーションのドキュメントルートにない、アプリケーションに関連するすべてのものが含まれています。ノードは、アプリケーションのパブリックドキュメントツリーの一部ではありません。ディレクトリに含まれるファイルは、コンテナによってクライアントに直接提供できません。ただし、ディレクトリのコンテンツは、 の およびメソッドの呼び出しを使用してサーブレットコードから表示でき、呼び出しを使用して公開できます。WEB-INFWEB-INFWEB-INFgetResourcegetResourceAsStreamServletContextRequestDispatcher

これは、WEB-INFリソースがWebアプリケーションのリソースローダーにアクセス可能であり、一般に公開されていないことを意味します。

このため、多くのプロジェクトでは、JSPファイル、JAR /ライブラリ、独自のクラスファイルやプロパティファイルなどのリソースや、その他の機密情報をWEB-INFフォルダに入れています。それ以外の場合は、単純な静的URLを使用してアクセスできます（たとえば、CSSまたはJavaScriptをロードするのに役立ちます）。

JSPファイルは、技術的な観点から見ると、どこにあってもかまいません。たとえば、Springでは、これらをWEB-INF明示的に構成することができます。

<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver"
    p:prefix="/WEB-INF/jsp/" 
    p:suffix=".jsp" >
</bean>

ウィキペディアの中で言及したフォルダにWARファイル記事は、実行時にサーブレット仕様で必要とされるフォルダの例です。WEB-INF/classesWEB-INF/lib

プロジェクトの構造と結果のWARファイルの構造を区別することが重要です。

プロジェクトの構造は、WARファイルの構造を部分的に反映する場合があります（JSPファイルやHTMLおよびJavaScriptファイルなどの静的リソースの場合）が、常にそうであるとは限りません。

プロジェクト構造から結果のWARファイルへの移行は、ビルドプロセスによって行われます。

通常、独自のビルドプロセスを自由に設計できますが、今日ではほとんどの人がApache Mavenなどの標準化されたアプローチを使用します。特にMavenは、プロジェクト構造のどのリソースが、結果のアーティファクトのどのリソースにマップされるかについてのデフォルトを定義します（この場合、結果のアーティファクトはWARファイルです）。マッピングがプレーンコピープロセスで構成される場合もあれば、フィルタリングやコンパイルなどの変換がマッピングプロセスに含まれる場合もあります。

1つの例：WEB-INF/classesフォルダーには、アプリケーションを起動するためにクラスローダーによってロードされる必要があるすべてのコンパイル済みJavaクラスおよびリソース（src/main/javaおよびsrc/main/resources）が後で含まれます。

別の例：WEB-INF/libフォルダーには、後でアプリケーションが必要とするすべてのjarファイルが含まれます。Mavenプロジェクトでは、依存関係が自動的に管理され、Mavenは必要なjarファイルをWEB-INF/libフォルダーに自動的にコピーします。これlibが、Mavenプロジェクトにフォルダーがない理由を説明しています。

Java EE Webアプリケーションをデプロイする場合（フレームワークを使用するかどうかにかかわらず）、その構造はいくつかの要件/仕様に従う必要があります。これらの仕様は、

• サーブレットコンテナ（Tomcatなど）
• JavaサーブレットAPI
• アプリケーションドメイン

1. サーブレットコンテナーの要件
   Apache Tomcatを使用する場合、アプリケーションのルートディレクトリをwebappフォルダーに配置する必要があります。別のサーブレットコンテナまたはアプリケーションサーバーを使用している場合は、異なる場合があります。
   
   

2. JavaサーブレットAPIの要件
   JavaサーブレットAPIでは、ルートアプリケーションディレクトリは次の構造でなければならないことが規定されています。

   ApplicationName
   |
   |--META-INF
   |--WEB-INF
         |_web.xml       <-- Here is the configuration file of your web app(where you define servlets, filters, listeners...)
         |_classes       <--Here goes all the classes of your webapp, following the package structure you defined. Only 
         |_lib           <--Here goes all the libraries (jars) your application need

これらの要件は、JavaサーブレットAPIによって定義されています。

3.アプリケーションドメイン
サーブレットコンテナ（またはアプリケーションサーバー）の要件とJavaサーブレットAPIの要件を満たしたので、必要に応じてWebアプリケーションの他の部分を整理できます。
-リソース（JSPファイル、プレーンテキストファイル、スクリプトファイル）をアプリケーションのルートディレクトリに配置できます。しかし、そうすれば、アプリケーションが提供するロジックによってリクエストが処理される代わりに、ブラウザから直接アクセスできます。したがって、リソースがそのように直接アクセスされるのを防ぐために、サーバーからしかアクセスできないコンテンツをWEB-INFディレクトリに配置できます。
-一部のフレームワークを使用する場合、多くの場合、構成ファイルを使用します。これらのフレームワークのほとんど（Struts、Spring、Hibernate）では、構成ファイルをクラスパス（「classes」ディレクトリ）に配置する必要があります。

公開したくないページまたはページの一部をWEB-INFに配置する必要があります。通常、JSPまたはファセットはWEB-INFの外部にありますが、この場合、どのユーザーも簡単にアクセスできます。許可制限がある場合は、WEB-INFを使用できます。

WEB-INF / libには、システムレベルでパックしたくないサードパーティライブラリを含めることができます（JARは、サーバーで実行されているすべてのアプリケーションで利用できます）が、この特定のアプリケーションに対してのみ可能です。

一般的に言えば、多くの構成ファイルもWEB-INFに入ります。

WEB-INF / classesと同様、すべてのコンパイル済みソース（JARSではなく、自分で作成したコンパイル済み.javaファイル）が配置されるフォルダーであるため、任意のWebアプリに存在します。

この規則は、セキュリティ上の理由から守られています。たとえば、権限のないユーザーがURLから直接ルートJSPファイルへのアクセスを許可されている場合、認証なしでアプリケーション全体をナビゲートでき、保護されたすべてのデータにアクセスできます。

ディープリンクやブックマークができないように、jspページをWEB-INFディレクトリの下に配置する規則があります（必須ではありません）。このようにして、jspページへのすべてのリクエストはアプリケーションを介して送信される必要があるため、ユーザーエクスペリエンスが保証されます。