Java Webアプリケーションのフォルダー構造

J2EEの初心者として、最近、Core of J2EE：Servlets＆Jspsを使用して、ゼロから独自のプロジェクトの開発を開始しました。

プロジェクトのフォルダー構造が正しいかどうかを評価できませんでした。これが私のプロジェクトのフォルダ構造です。

質問をする前に、誰かが私に尋ねたとしても、なぜこのタイプのフォルダー構造なのか、答えることも正当化することもできません。質問：jspをweb-infの外に置くのは良い兆候ですか？そうでない場合、なぜそうなのですか？はいの場合、なぜですか？

J2EE Webアプリケーション用の標準的なフォルダー構造の規則はありますか、mavenがいくつかの標準を導入したことは知っていますが、それでも、要件に応じてカスタマイズできます。

私は少しグーグルをして、2つの参照を見つけました 1 2

答えが同じページになく、そこから結論を引き出すことはできませんでした。

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に入れたものは外部からアクセスできないことですが、WARのルートディレクトリにあるものはすべてパブリックです。

web.xmlで定義したサーブレットとフィルターを使用して、アプリケーションがすべてのアクセスを処理するようにするため、通常はルートに多くを配置したくないでしょう。ルートにindex.html（または.jsp）があり、たとえばStrutsアクションなどのサーブレットにリダイレクトすることがよくあります。

StripesやStrutsなどの典型的なMVC実装では、ユーザーがJSPに直接アクセスすることをお勧めせず、JSPを表示専用にすることをお勧めします。リクエストの処理後にJSPに転送するコントローラーを作成することをお勧めします。JSPは結果を表示するだけです。たとえば、フォームを送信する/loginと、ログイン要求を処理し、ユーザーのセッションを作成し、ユーザーをホームページJSPのログインビューに転送するアクションが実行されます。

「正しい方法は何ですか」に対する通常の答え。または「これは正しい方法ですか？」それは..... に依存します。

私にできることは、特定のアイデアの長所と短所を伝えることだけです。続くものは私の意見100％です。特定の要件やルールについては知りません。誰かが私に反対すると思う。

JSP

JSPをWEB-INFに配置するかどうかを検討しましょう。

JSPをWEB-INFに配置する利点：

• JSPの実行方法を制御します。JSPをパラメーター化して再利用できるようにする場合（JSPを使用するのは非常に困難です）、それらをWEB-INFに配置し、サーブレットまたはStrutsアクションコントローラーまたは他のフロントコントローラーを使用して前処理を行うことができます次に、制御をJSPに渡し、適切な環境コンテキスト（要求属性、セキュリティチェック、パラメーターのサニテーションなど）を渡します。
• プログラムで、またはファイアウォールまたはIDSレベルで* .jspへのHTTP要求をブロックして、誰かがJSPをWebルートにアップロードし、Webサーバーとしてコードを実行できる可能性を減らすことができます。既存のJSPを上書きする必要があります。大幅なセキュリティの向上はありませんが、妥協が少し難しくなります。
• すべての作業自体を実行し、読み取り/保守が難しい巨大な大規模なJSPとは対照的に、MVC、フロントコントローラー、サーブレットフィルター、依存性注入などの良い習慣を強制します。

JSPをWEB-INFに配置することの短所：

• 前処理を必要としない単純なスタンドアロンページであっても、ページに直接アクセスすることはできません。これは、/ WEB-INFの下にあるファイルがサーブレットコンテナによって処理できないためです。

静的ファイル

HTML、画像、スタイルシート、javascriptなどの純粋に静的なファイルに関しては、それらをWebルート（あなたの場合はmy_app）の下に置きますが、/ WEB-INFではありません（アクセスできないため）。

全体のレイアウト

全体的なディレクトリレイアウトに関しては、ビルドプロセスによって多少異なります。「src」または「source」の下にすべてを保存するのが好きです。なぜなら、ビルドによって生成されるファイルと純粋なソースファイルが明確になるからです。 mainjunitクラスのようなテストコードをメインソースコードから分離できます。ただし、単体テストがない場合（そうだよ！）、それは無意味な区別です。

一方、ビルド中に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ページの一部であることに注意してください。

テンプレートのように、部分的なフォルダ名を使用できます。見知らぬ人にとっては見つけやすいはずです。全ページ、テンプレート、部分ビューなど、さまざまな種類のコンテンツを分離するだけです...

ブライスに同意します。私もJ2EEの初心者ですが、最初は簡単かつ明確に作業する方が良いと思います。

ルートフォルダはWEBAPPであり、ほとんどのページがそこにあると考えてWeb構造を作成する必要があります。そうでない場合、ページ間でページが通信するときに、エラーなしでファイルの関係を管理できない可能性があります。

実際、WARアプリケーションはなしで構築できWEB-INF/web.xmlます。内部にJavaクラスのみを含むWARアプリケーションを作成することができます。

ソース：web.xmlデプロイメント記述子の要素

Java EEアノテーションでは、標準のweb.xmlデプロイメント記述子はオプションです。http://jcp.org/en/jsr/detail?id=315のサーブレット3.0仕様によれば、サーブレット、フィルター、リスナー、タグハンドラーなどの特定のWebコンポーネントで注釈を定義できます。

だから、最近では.war拡張機能付きのJARのように見えるよりもWARを構築することが可能です

質問に答える場合、WAR構造は要件によって異なります。

http://en.wikipedia.org/wiki/WAR_(Sun_file_format）