How are path related values of the request object changed after a forward or include?

memo

winstoneのRequestDispatcherを覗いているときに発見した事実。つーか，正直あまり気にしたこと無かった。


RequestDispatcher.include()/forward()したときのRequest URIの挙動について。includeの方は，Servlet2.3のころ（SRV.8.3.1）から定義されていたようなのだが，forwardは，Servlet2.4（SRV.8.4.2）で定義されたもよう。
＃まあ，どっちも知らなかったんで，威張って言うほどのモノではない。:-)


ここにも書いてあった。
→Servlet 2.4: What's in store - RequestDispatcher changes

続きを読む

RequestDispatcherが一番大事

winstone

大抵のAPサーバがリクエストを処理する実行スレッドを持っているところまでは，それとなく分かっていたが，実際にスレッドの中で何が起きているかまでは理解しきれてなかった。


winstoneも例に漏れず実行スレッド（RequestHandlerThread）を持っているワケなんだが，そこで何が行われているかというと，だいたいこんな（↓）ことが行われている。

RequestHandlerThread.run()
 → RequestHandlerThread.processRequest()
     → WebAppConfiguration.getInitialDispatcher()
     → RequestDispatcher.forward()
         → ServletConfiguration.execute()
             → Servlet.service()

日本語で簡単に言うと，

  1. URIに相当するRequestDispatcherを取得（大抵はServletかJSP）
  2. 取得したRequestDispatcherにフォワードする（ここでServlet.service()が呼ばれる）。

となる。


つまり，ふつーにServletやJSPが呼ばれてるのも，コンテナ内で相当のRequestDispatcherを作っているに他ならないって事だ。
普段，あんまり気にしないで使っていたRequestDispatcherが実は処理の中核だったというワケか。
＃あくまでwinstoneの実装の話だけど，他のAPサーバも似たり寄ったりだと思う。

winstoneのコード読んで思うこと

winstone

APサーバ（少なくともサーブレットコンテナ）について，大概のことは答えられるようになった。これはデカイ。
ちょうど講師してたってこともあるけど，読んでおいて損することはないな。


ps.
JSPの場合は，jasperのコード読まなくても，JSPから変換されたJavaのコード読むだけで十分勉強になる。

Java6時代のWARファイルでDataSourceは必要かなぁ？

memo

タイトルがイマイチ。


Derbyなどの組込型RDBMSを使う場合，JDBCドライバやヘタをするとDBそのものもWARファイルにまとめられるようになる。そうなった時，DataSourceをわざわざAPサーバの管理リソースにする必要ってどんだけあるんだろうか？などとつらつら思う。
＃Java6でDerbyだったらJDBCドライバを添付する必要もない。


コネクションプール程度ならDBCPで何とかなるし，せいぜいモニタリングくらいか？これだって，解決しようはあるよなー。 そう思うと，WARファイルで完全に完結するアプリが作れるのに，わざわざAPサーバの管理リソースを使う理由ってどんだけあるんだろう？

続きを読む