私はかなり長い間、主に Spring 3.1.x と 3.2.x で、サーブレット環境で Spring MVC を使用して開発を行ってきましたが、最近、Spring 3.0.6 を使用してポートレットとサーブレットを組み合わせて使用する会社に仕事を移しました。
まず、 DefaultAnnotationHandlerMapping には、 Portlets用とServlets用の 2 つのバージョンがあるようです。ポートレットに関する知識が限られているため、ポートレットはサーブレットを拡張したものにすぎないと思い込んでいます。そのため、1 つは一般的なサーブレットを処理し、もう 1 つはポートレスト固有のものを処理するために、2 つの別個の HandlerMapping が必要であることを漠然と理解できます。私を投げかけているのは、 @RequestMapping アノテーションの処理方法と、私の新しい雇用主が物事をセットアップするために選択した方法に関して、それぞれが異なる動作をしているように見えることです。
以前は、アプリケーション全体に対して 1 つの DispatchHandler がありました。複数の DispatchHandler を持つことができることは知っていますが、サブコンテキスト XML の分離を超える利点は見たことがありません。とにかく、過去には DispatchHandler を "/" にマップし、次に各コントローラーが @RequestMapping("/someUrl") を使用してその上にマッピングを設定し、次に各ハンドラー メソッドで別の @RequestMapping をさらに拡張して URL マッピングを設定しました。したがって、ブラウザから次のようなものが得られます。
ここで、最初の "/myWar" は WAR デプロイメントにマップされ、次の "/" は DispatchServlet にマップされ、"/myController" はコントローラーのマッピングであり、その後は URL 署名、リクエストの組み合わせを使用して何らかのメソッドに一致しますメソッド、パラメータなど
では、新しい会社で私が見ているものを評価してみましょう。最初に、各コントローラーは独自の DispatchServlet を取得するため、20 ～ 30 の DispatchServlet が定義され、すべて異なるベース URI がマップされ、同じベース Application Context XML を持つものもあれば、異なるものもあり、すべて ContextLoaderListener から同じ Application Context を使用します。後続の DispatchServlet のパスはそれぞれ、「マップされた」コントローラーの @RequestMapping と同じであるため、上記の例では、DispatchServlet はパス「/myController」を持ち、コントローラーは @RequestMapping("/myController") を持ちます。その上、コントローラーのメソッド レベルでは、@RequestMapping で指定された値は、それに適用される追加のパスを完全に無視するようです。
たとえば、@RequestMapping("/myController") を持つコントローラーがあり、その後に @RequestMapping("/edit") を持つメソッドが続く場合、URL http://somehost.com/myWar/myContoller/editにアクセスします。しかし、メソッドレベルの @RequestMapping を @RequestMapping(parameter="actionMethod=edit") に変更し、URL をhttp://somehost.com/myWar/myController?actionMethod=editに変更すると、マップは問題なく、ページが表示されます。さらに、メソッドレベルの @RequestMapping を @RequestMapping(value="/edit",params="actionMethod=view") に変更すると、http://somehost.com/myWar/myController?actionMethod=editでもhttp:/ /somehost.com/myWar/myController/edit?actionMethod=editまったく働きます。問題は、メソッド レベルでデフォルトのマッピング以外のものに到達するには、パスを追加して URI を単純に拡張するのではなく、"?actionMethod=edit" を実行する必要があることです。また、@RequestMapping("/somePath/{id}") のようなものを定義できないため、RESTful なアプローチを使用できなくなります。
web.xml の DispatchServlet マッピングがコントローラーの @RequestMapping と重なっている理由や、value プロパティを有効な URI マッピングに設定したときに、コントローラーのメソッド レベルの @RequestMapping が機能しない理由など、頭の中で非常に混乱しています。 、しかし、パラメーターマッピングを設定すると正常に動作しますか?
あ、あと長文失礼しました。ここで何が起こっているのかをよりよく理解したいので、インテリジェントなアプローチで対処するか、新しいグループに戻って「これは変更する必要があり、これが理由です」と言うことができます。役立つ場合は、いくつかの単純化されたコード例を使用して、この長い質問を拡張できます。