Java Servlet 3.0 API: What’s New and Exciting
Pluggability web.xmlに直接触れるAPIが追加される為、 ServletAPIを使うFrameworkは、それ専用の設定ファイルを持つ必要がなくなる。 今は、web.xmlにServletFilter書いて頑張ってるよねぇ…とか。 それについて、ドキュメント書くのダルくね？とか。 それぞれのFrameworkは、それぞれのjarにMETA-INF/web.xmlをおいて使う。 そのweb.xmlをWebコンテナが気合で探す。 ポイントは、タグ。まぁ、中身は既存のweb.xmlと同じ様な感じ ServletContextに、web.xmlへアクセスするためのメソッドを追加しる。 -Servletの追加 -Filterの追加 -URLマッピングの追加 何と言うか、JettyのAPIとほぼまんま一緒。addServletとか、addServletMappingとかある。 でも、ServletのライフサイクルをServletコンテナの外側で管理出来るのかな？… Ease of Development web.xmlの存在がオプションになる。JSPや静的リソースだけの場合には、web.xmlイラナイ。ｽﾊﾞﾗｼ。 convention over configurationらし。 annotationで、Servletとしての定義が出来るですだよ。 @Servlet @GET @PUT @HttpMethod @Servlet(urlMapping={"/foo"}) public class FooServlet { @GET public void exec(HttpServeltRequest req,HttpServletResponse res) { } } まぁ、Filterやそういうのも、大体一緒。 web.xmlで、annotationに記述された内容を上書き出来るですだよ。 でもさ、これって、ClassLoaderは、どうやってサーブレットクラスを探すんだろ… ディレクトリトラバーサルしないとダメなんじゃね？ つまりは、特に仕様に記述されないだろうけど、 ServletContainerの起動処理が、やたら重くなる可能性はないかぇ？ Async Servlet Support Commet Support StreamingやらLong pollingやら実装方法は、色々あるけど、そこには触れないよぅ、とか。 Request ca b suspended and resumed. ウゴゲ…、これはAPI叩くの難しくなるんじゃねぇかなぁ… 普通に、NIO使った、event dispatchモデルをガッツリ使いこなさないと、 すぐDeadLockしたりとか、メモリ不足になったりするんじゃねぇかなぁ… いや、メソッド並べると簡単だけどさ、それぞれをちゃんと呼ぶのはマジキツイぞ… ServletRequestListenerってのが増えるのか。これは、簡単に使えそう。 いや、簡単にRequestをSuspendとか言ってるけど、これって、別のスッドレに、処理をDispatchしないとダメじゃん。 JMSみたいなの使わない限りは、ここ自前実装だぞ。OH!Deadly! Security enhancements login and logout www-authenticat ヘッダを使う HttpSessionを使って、状態を維持しる 仕様の内容については、まだfixしている訳では無くて、 ExpertGroupで引き続きディスカッションしている。 HttpOnlyCookieをサポート んぁ？これどうやって実装すんだ？ｲﾐﾜｶﾝﾈ。 CSS対策になる…とか。これって、XHRで、ヘッダ偽装したら結局Cookieを返さざるを得ないよね？ Session tracking cookie を、設定可能にしる。 これって、今までは、サーバ依存な設定項目だったけど、標準になるのだに。 EJBをwarファイルの中に含められる様にするつもりがあるらしい。 まぁ、earファイルの中にある超絶jar構造は、マジメンドクセｪ。 そうは言ってもEJBなんて、どうせ使わないから、いいけどねぇ…
