このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
web.xml で Servlet の設定をすることで、
Web アプリケーションに届く要求を処理することができる。
ということは、Web アプリケーションを作るには、
Servlet インタフェースを実装したクラスを自ら作成し、
そのクラス名を web.xml に登録すればいいのだ。
では、javax.servlet.Servlet インタフェースを見てみよう。
・ServletConfig getServletConfig()
・String getServletInfo()
・void init(ServletConfig config)
・void destroy()
・void service(ServletRequest req, ServletResponse res)
これは、あまりにも単純な構造だと思わないだろうか。
getServletConfig や getServletInfo は、
Servlet の情報を取得するためのものだし、
init と destroy は、初期化と後始末のためのものだ。
となると、要求を処理するのは service() のみである。
そう、Servlet を自ら実装する場合、
web.xml の設定によって Servlet に到達した要求はすべて
このメソッドで処理されることになる。
考えてもみよう。URL のマッピングは、
<servlet-mapping> 等で指定するわけだ。
例えば、*.exec という URL パターンを指定したとすると、
パス部分が .exec で終わる「あらゆる URL 要求」が、
このメソッドに到達することになる。
となると、service メソッドで行わなければならないのは、
以下のような処理ということになる。
1. アクセスのあった URL が正しいか検証する。
2. 不正なら別の URL に転送するか、HTML 等を出力。
3. URL を元に、どの処理を実行するかどうかを決める。
4. 必要に応じてフォームやパラメータを検証する。
5. 不正なら別の URL に転送するか、HTML 等を出力。
6. 処理を実行する。（最も複雑な部分）
7. 処理の結果に応じて、表示する HTML 等を出力。
全てのロジックが service() メソッドに集中するため、
ある意味、究極の自由度を手に入れることになる。
その気さえあれば、Servlet を実装したクラス 1 つだけで、
Web アプリケーションを書くことは可能である！（笑）
しかし、これはあまりにも低水準すぎる。
これらを順に実装していくのは非常に大変で、
現実的な作業量とは言いがたい。
そこで出てくるのが、JSP や Struts 1.x といった、
汎用の Servlet 実装なのである。