Java Webアプリケーションのフォルダ構造
J2EEの初心者として、私は最近、J2EEのコアであるサーブレットとJspを使用して独自のプロジェクトをゼロから開発し始めました。
プロジェクトのフォルダー構造が正しいかどうかを評価できませんでした。これが私のプロジェクトのフォルダー構造です。 
質問する前に、なぜこのタイプのフォルダ構造なのかと尋ねられても答えられなかったか、正当化できなかったことを認めます。質問：私のjspをweb-infの外に置くことは良い兆候ですか？そうでない場合、なぜそうなのですか？はいの場合、なぜですか？
J2EE Webアプリケーションに標準のフォルダー構造の規則はありますか。Mavenがいくつかの標準を提起したことは知っていますが、それでも、私は信じている要件に従ってカスタマイズできます。
答えが同じページになく、そこから私は結論を出すことができませんでした。
J2EE Webアプリケーションのフォルダー構造をレイアウトする際に考慮すべき点は何ですか。重要なのは、JSP、静的コンテンツをどこに配置する必要があるか、およびその理由は何ですか。
WARファイルの標準的な構造は次のとおりです。
/META-INF
Standard jar stuff like manifest.xml
/WEB-INF
web.xml
/classes
/com...etc.
/lib
Mavenはこれをsrc/main/Java、リソース、webapp、および依存関係（/ libに配置）を使用して maven-webapp-plugin に生成しますが、これは実装です。認識すべき重要なことは、WEB-INFに置くものはすべて外部からアクセスできないであるのに対し、ルートディレクトリ内のすべてのものは戦争の公開です。
アプリケーションはweb.xmlで定義したサーブレットとフィルターを使用してすべてのアクセスを処理する必要があるため、通常はルートに多くを入れたくありません。ルートにindex.html（または.jsp）がサーブレットにリダイレクトされるのはよくあることです。たとえば、 Struts アクションです。
StripesやStrutsなどの一般的なMVC実装では、ユーザーがJSPに直接アクセスすることはお勧めしません。JSPは表示専用にすることをお勧めします。リクエストの処理後にJSPに転送するコントローラーを作成することをお勧めします。JSPは結果をレンダリングするだけです。たとえば、フォームを/loginに送信すると、ログイン要求を処理するアクションが実行され、ユーザーのセッションが作成され、ユーザーがホームページのJSPのログインビューに転送されます。
「正しい方法は何ですか？」に対する通常の答えは？または「これは正しい方法ですか？」 is ..... 場合によります。
私にできることは、具体的なアイデアの長所と短所を説明することだけです。以下は100％私の意見です。特定の要件やルールは知りません。きっと誰かが私に反対するでしょう。
JSP
JSPをWEB-INFに配置するかどうかを検討しましょう。
JSPをWEB-INFに配置する長所：
- JSPの実行方法を制御します。 JSPをパラメーター化して再利用できるようにする場合（とにかくJSPでは難しい）、それらをWEB-INFに配置し、サーブレット、Strutsアクションコントローラー、またはその他のフロントコントローラーを使用して前処理を行うことができます。次に、JSPに制御を渡し、適切な環境コンテキスト（リクエスト属性、セキュリティチェック、パラメーターサニテーションなど）を渡します。
- プログラムによって、またはファイアウォールまたはIDSレベルでも、*。jspへのHTTPリクエストをブロックして、誰かがJSPをWebルートにアップロードし、コードをWebサーバーとして実行する可能性を減らすことができます。既存のJSPを上書きする必要があります。大きなセキュリティの向上はありませんが、妥協が少し難しくなります。
- MVC、フロントコントローラー、サーブレットフィルター、依存性注入などの適切な習慣を強制します。大規模な巨大なJSP自体はすべての作業を実行し、読み取り/保守が困難です。
JSPをWEB-INFに配置することの短所：
- 事前の処理を必要としない単純なスタンドアロンページであっても、ページに直接アクセスすることはできません。これは、/ WEB-INFの下のファイルがサーブレットコンテナによって提供されないためです。
静的ファイル
HTML、画像、スタイルシート、JavaScriptなどの純粋に静的なファイルに関しては、それらをWebルート（あなたの場合はmy_app）の下に配置しますが、/ WEB-INFには配置しません（アクセスできないため）。
全体的なレイアウト
全体的なディレクトリレイアウトについては、ビルドプロセスによって多少異なります。 「src」または「source」の下にすべてを保存するのが好きです。ビルドによってどのファイルが生成され、どのファイルが純粋なソースファイルであるかが明確になるからです。 mainを使用すると、junitクラスなどのテストコードをメインのソースコードから分離できます。しかし、ユニットテストがない場合（ああ、違います！）、それは意味のない区別です。
一方、ビルド中にWebルートをまったく操作しない場合（すべてのJSPと静的ファイルの場合など）、おそらく/webrootまたは/deployなどの最上位に保持し、必要に応じてファイルをコピーします。 .classファイルや.jarファイルなど。過度に組織化するのは、人間（特に開発者）の習慣です。過度に整理していることの良い兆候は、単一のサブフォルダーのみを持つ多数のフォルダーがあることです。
表示した内容
Mavenによって設定された規則に従っていることを示したので、すでにmavenを使用している場合は、そのレイアウトをそのまま使用してください。あなたが説明したレイアウトには何の問題もありません。
さて、あなたのsrc/main/webappは確かにMavenプロジェクトを思い出させます。どっちがいい。
My_app/jspsについてはわかりません。開発者は通常、jspをwebappフォルダーに残します。または、URLマッピングを少し実行したい場合は、webapp/jspディレクトリに残します。
！警告！ ：jspファイルをweb-infに配置しないでください。 WEB-INFには、Webサイトを構成するためのxmlファイルのみを含める必要があります。 jspはWebページまたはWebページの一部であることを忘れないでください。
テンプレート、パーシャルなどのフォルダ名を使用できます。見知らぬ人が見つけやすいはずです。フルページ、テンプレート、部分ビューなどの異なるタイプのコンテンツを分離するだけです...
実際、WARアプリケーションはWEB-INF/web.xmlなしで構築できます。内部にJavaクラスのみを含む）でWARアプリケーションを作成することが可能です。
Java EEアノテーションでは、標準のweb.xmlデプロイメント記述子はオプションです。 http://jcp.org/en/jsr/detail?idのサーブレット3.0仕様によると、 = 315 、アノテーションは、サーブレット、フィルター、リスナー、タグハンドラーなどの特定のWebコンポーネントで定義できます。
したがって、今日では、.war拡張子を持つJARのように見えるよりもWARをビルドすることが可能です:)
質問に答えると、WARの構造は要件によって異なります。
私 Briceに同意する 。私もJ2EEの初心者ですが、最初はわかりやすく、わかりやすくした方がいいと思います。
ルートフォルダーはWEBAPPであり、ほとんどのページがそこに配置されると考えてWeb構造を作成する必要があります。そうでない場合、ページがページ間で通信するとき、おそらくエラーなしでファイルの関係を管理することはできません。