JSR-315がServlet 3.0仕様のパブリック・レビュー(PR)を公開した。またそれに合わせGlassFish (リンク)のトランクで参照実装が提供された。今回のリリースがエキスパート・グループ(EG)が選択した次世代のServlet APIとJava EE 6プラットフォームに関する物議をかもしている。
Servlet APIは常々詳細な部分については荒削りで、またEarly Draft段階 (参考記事)であるためにJSR 315のEGはEase of Development (EOD)、プラグイン化、そして非同期処理のサポートといった分野について洗練と改良を続けている。この点についてスペック・リードの一人であるRajiv Mordani氏は以下のように述べている。
- Ease of Development (Eod): Early Draftで主にServletをPOJOとして作成するためのアノテーションを追加しました。しかしエキスパート・グループ内での議論とコミュニティの数人から得たフィードバックを基に、私たちはメソッド・レベルのアノテーションである@GET、@POSTを無くしてdoGet、doPostといったメソッド名の制約とHttpServletの継承を残すことにしました。一方でトップレベルのアノテーションはより使い勝手をよくするために名称が変更されたものの、残されています。@WebServletアノテーションはサーブレットを宣言するため、@ServeltFilterはフィルタ、@WebServletContextListenerはServletContextListenerをそれぞれ宣言するために使われます。これらのアノテーションに加えて@ResourceのようにServlet 2.5からサポートされるようになったアノテーションも引き続き使うことが出来ます。
- プラグイン対応:サーブレットの仕組みの上に構築されたWebフレームワークは開発者にとってとても馴染みのあるもので、異なる領域に特化した様々なフレームワークが存在しています。開発者がWebアプリケーションを作るに当たってフレームワークをより便利に使えるようにするため、私たちはサーブレット3.0の仕様で開発者がより簡単に好きなフレームワークを使ったり設定できるような機能を追加しました。
- 非同期処理: これがサーブレット3.0の仕様でもたらされた最大の変更点になります。Early Draftではそれまで定義されていた多くの記述法について取り止めたり、再開したりしました。しなしながらEarly Draftの後に非同期処理に関する様々な用途についてエキスパート・グループで多くの議論を重ねた結果、この分野の仕様は多くの用途に対応できるように変更されています。
Roy Van Rijn氏はEarly Draftに登場するいくつかの機能に関する自分の考えを以下のように表現した(リンク)。
私はいまだにGET/POSTメソッドには絶対にアノテーションを使わない方がいいと思っていますが、Java EE 6の仕様書ではこのようなアノテーションを使うことを推奨している上にJSR-315の作者たちは選択肢を用意していません(ひどいことです)。この記事に記したコメントはJSRグループに送りましたが、まだ返事はありません。
さらにJSRのメンバに説明・解説・対応を求めようとしても接触できていません。最近Java EE 6の仕様書がパブリック・レビューになり、それにはServlet 3.0の仕様について言及されていますので恐らくはJava EE 6に含まれることでしょう。これはつまり現在も活動中であるということを意味しています。もしかしたら期限に間に合わせるために半狂乱で活動しているかもしれません。でも、私はアノテーションに関する決定について再考してもらえるよう嘆願しました。
パブリック・レビュー(PR)のリリースについてWebtide社のGreg Wilkins氏はその仕様を「調和の取れていないエキスパート・グループ(EG)が欠点だらけのプロセスを通して生み出した貧相なドキュメントである」(リンク)と評している。氏のPRに対する主な論点は以下の通りである。
- これはAPI設計に関する思考実験で、それが複雑な実装と試験的な使用またはコミュニティからのフィードバックによって後押しされたに過ぎない。
- 試験的な実装を依頼したものの拒否された。
- コミュニティから寄せられた要求の正当性を判断するためのオープンであるかまたはよく練られた機構がなく、ほとんどコミュニティと協議をしていない。
- 用途もユーザからの要求もない何の根拠もない要件(例えば、非同期リクエストのラップ)が終わりに近い段階になって追加された。
- ほとんどのJCPドキュメントに言えることであるが、ドキュメントの出来が悪い。
- 新たに追加された機能のいくつかがセキュリティ上の問題やデプロイの遅延を招く恐れがある。
- 非同期サーブレットに関する計画がEarly Draftの頃に対して方向転換してしまった。当初のアプローチはJetty Continuations(リンク)の成果であり、2008年3月以降(リンク)、Cometd(リンク)、DWR(リンク)、JSF(リンク)そしてBlazeDSな(リンク)どを含む多様なフレームワークやアプリケーションによってテストされたJetty-7のプレリリースに含まれる試験的実装として手に入れることが出来た。
Greg氏は以下のよう結論付けている。
現在のPRには多くの重大なエラーが含まれていると思います。そして、プロセスの欠陥があまりにヒドイためにこれらの欠陥が適正に評価されずに自明となったのです。これらの問題についてEGからのサポートがありましたが、スペック・リードに対して彼らの正当性を納得させることはできませんでしたし、過剰な議論をしてもこれらの発生を抑えることは出来なかったと思います。
Rajiv氏(リンク)はGreg氏の指摘に対して以下のように答えた。
- 実装はGlassFishで手に入る
- Greg氏からフィードバックを要求された覚えがない
- 新しい機能は不要であれば使わないことも出来る
- デプロイが遅延する明確な根拠がない
- 非同期サーブレットに関する提案はコミュニティを中心に広まっていったのにもかかわらずGreg氏はEGにメールをした。
Rajiv氏はさらにRedHat社のBill Burke氏のブログを引用した。そのブログではJetty 6 continuationsによる非同期サーブレットの実装が非難されている(リンク)。
最後に、Greg Wilkins氏は自身がブログ内で提案した修正案/拡張案を利用してServlet 3.0準拠の非同期サーブレットを実装しているということを公表している(リンク)。EG内で継続している議論によればその内容とは以下のようなもののようである。
- 再ディスパッチされた非同期リクエスト向けに新しくASYNCというDispatcherTypeを追加
- リクエストが再ディスパッチされた場合にisAsyncStarted()メソッドはfalseを返す。
- getReader()かgetOutputStream()を呼び出した後にstartAsync()やstartAsync(request, respone)が呼び出されるとIllegalStateExceptionが投げられる。これによってシンプルなクラスが非同期ハンドラを使うことを制限する。
- startAsync(request, response)によって非同期モードが開始された場合、AsyncContextのfoward(...)系のメソッドを実行することはIllegalStateExceptionにつながる。これによって再ディスパッチ用のラッパー・クラスが複雑化するのを抑制しつつ非同期ハンドラ内でラッパー・クラスを使うことを許容する。
- forward(path)及びforward(context, path)メソッドは実装していない。
コードはJettyのブランチ(リンク)及び、servlet-apiのブランチ(リンク)で手に入る。
Greg氏は非同期サーブレットの問題についていかのようにまとめた。
さらなるテストが必要なものの、この実装によってラップされたリクエストを再ディスパッチしたりforward(path)メソッドを実装したりすることなくかなりの非同期的な振る舞いを実装することが出来るということが示されました。この実装が3.0の落としどころとなると信じています。もしさらなる機能が必要となれば、3.0のシンプルなサブセットで十分な経験を積んだ後で3.1に追加すればいいことです。
Servlet(参考記事リンク)、GlassFish(参考記事リンク)、Jetty(参考記事リンク)、Comet(参考記事リンク)、そしてJava EE(参考記事リンク)に関するさらなる情報はInfoQにあります。