Mark Thomas氏(markt@apache.org)は、 今週ラスベガスで開催されたSpringOneプラットフォームカンファレンスの初日にApache Tomcatのロードマップを更新した。そこで彼は進行中のJava EE 8の遅れの事実を指摘した。以前InfoQでも強調したことである。またApache Tomcatチームで起こっている問題でもある。
Thomas氏は、Pivotalのコンサルタントソフトウェアエンジニアであるが、2003年からApache Tomcatのコミッタである。彼は次のことを強調した。プレゼンテーションはTomcatの将来について彼の個人的な見解を表している。それゆえにApacheソフトウェア財団やPivotalの見解を必ずしも表していないということだ。
ロードマップの観点から、Tomcat 9はサーブレット4.0のサポートを追加する予定である。実はこれは3つのカテゴリに分類される。エキスパートグループがすでに広く賛成していること、いくらか取り組んでいること、そしていくつかの可能性がある将来の計画だ。Thomas氏はこう述べている。
サーブレット4.0で合意した要素の点から、Thomas氏はアプリケーションがそれを見ていないだろうことを指摘したが、HTTP/2のサポートは含まれるだろう。実は、アプリケーションがHTTP/2とともに含まれるだろう唯一の場所はプッシュリクエストの上である。このためのAPIはエキスパートグループによって合意されており、Tomcat 9にですでに実装されている。
サーブレット4.0はまたリスナに一連のデフォルトのNO-OPメソッドを含んでいる。これは書く必要があるボイラープレートコードの量を減らすためである。類似した行に従って、HttpFilterの抽象ベースクラスが導入された。これはHttpServletに直接的に対応するものである。ServletRequestやHttpServletResponseそしてキャストを扱わなければならないというよりむしろ、HttpServletRequestとHttpServletResponseを扱うことができるということだ。Thomas氏は次のように言った。
協議中のことは現行のサーブレットへリクエストをどのように対応させるかである。すなわち拡張マッピングやパスマッピング、かつ/またはそのマッピングにおいてワイルドカードに実際にマッチするURLのどこか一部で対応させるかどうかである。これはJSFのエクスパートグループがうちか欲していたものである。そして彼らはTomcatにおいていくつか微調整して実装されたAPIを提案した。そしてそれはJettyでも現在は実装されている。しかしながらサーブレット4.0のエキスパートグループにはまだ合意されていない。
協議中の他の2つは、リクエストパラメータへのノンブロッキングアクセスである。これはリクエストボディをノンブロッキングで読むすでにある方法と似ているだろう。そして開発者がリクエストボディからノンブロッキングな方法でパラメータを読むことができることによってメカニズムを提供するだろう。そしてリアクティブのサポートだ。これはSpring 5の主なテーマである。
SpringとJettyの人々はサーブレットコンテナでのリアクティブのサポートについて議論を始めています。うまくいけばこれはTomcatのコミュニティを含むよう拡張すべきです。目的はJettyとTomcatの間で共有する、アプリケーションが使うことができる標準APIを持つことです。もしエキスパートグループがサーブレット4.0にこれがほしいと決めたなら、これはサーブレット4.0にリアクティブAPIを入れるためのことと同様に、よい開始モデルを私たちに与えてくれるでしょう。
しかしながらこのことを超えて、エキスパートグループから進展がないことはとても明白である。Tomcatがサポートする他の仕様に関して、JSPやUnified Expression Language、JASPIC (Java Authentication Service Provider Interface for Containers、これは本質的にプラガブルな認証プロバイダである)、WebSocketだが、「まったく何も起こっていない」とThomas氏は言った。
もし目下Java EE 8で起こっていることへのわかりやすい徴候がこれまでにあったなら、これはおそらく何も起こっていないということだけでしょう。彼らはまったく沈黙しています。
JASPICは少なくともだいたい安定していて全部揃っている。より問題があるのはJSPとUnified Expression Languageの仕様だ。Unified Expression Language 3はJSPに影響を与える一連の機能を追加したからである。しかしJSPの仕様はそれらを考慮して更新されていない。
単純な例は次のようなものです。Unified Expression Languageにおいて、あなたは今クラスをインポートすることができます。もしあなたがJSPページ上でExpression Languageの一部でそうしたなら、あなたがインポートしたクラスはJSPページで見えるようになるのか、それともならないのか？Tomcatでは見えますが、仕様にはそうすべきかそうすべきでないのかまったく書いていません。
なおより重大なのは圧縮や多重送信のようなことに対して拡張を書く標準APIがないWebSocketだ。これはWebSocket 1.0の作業の終わるころに話されたことだ。しかしそれからはっきりとした進展はない。
歴史的に、Tomcatのメジャーリリースは3つのことに依存してきた。関連する仕様が安定することと実装がTCKをパスすること(Tomcat 8ではこれは当てはまらないけれども)、 Tomcatコミュニティがコードベースが本番環境で実行するのに十分安定していると信用していることだ。
Java EE 8における問題は何も起こっていません。私たちは仕様がいつ最終決定する予定なのかを知りません。それが今年だったら私はびっくりするでしょう。来年でも私はおどろくでしょう。おそらくもっと先の2018年あたりでしょう。最終仕様の欠如は問題を引き起こします。Tomcat 9の大きな塊は今1年ほどでHTTP/2をサポートする準備ができているからです。
これがTomcat 8.5が導入されるだいたいの理由だ。Tomcat 8.5の9にはあるがJava EE仕様の一部ではない新しい機能はTLSサポートの重大な総点検を含む。Tomcat 8.0は1つのTLS仮想ホストにコネクタにつき１つの証明書を許可していた。Tomcat 8.5以降はホストにつき多数の証明書とコネクタにつき多数の仮想ホストに対するサポートを含む(これはSNIを通じて実装している)。
しかしながら、もう1つ興味深い欠点がここにある。サーブレット4.0はJava 8で実行しなければならず、HTTP/2をサポートしなければならない。HTTP/2はALPN (Application Layer Protocol Negotiation)とJSSEを必要とするが、Java 8ではALPNをサポートしない。
あなたは実際にピュアJavaで仕様に沿ってサーブレット4.0を実装をすることができないということを意味する。Tomcatチームがおよそ18ヶ月前に遭遇した問題だ。彼らはALPNをバックポートするよう頼んだが、これは断られた。Thomas氏によると次のようなことだ。
2、3週間前にIBMはおそらく彼らの実装で同じ核心に触れました。そしてエキスパートグループにちょうど同じ質問をしました。私は彼らも同じ回答を得るであろうと思います。
それゆえに現状Tomcatでは、ALPNをOpenSSLを暗号化するために必要とする。TomcatチームはOpenSSLをJSSE実装のように見せるためにラップしている。
JASPICサポートと同様に、Google OAuth2の設定例を含むことで、Tomcat8.5と9が仮想ホスト名へのワイルドカードのサポートを得て、相対HTTPリダイレクトや多くのの他の機能をサポートすることになるだろう。 検討中のことは、コンテナへのJava認証契約 (JACC)、JASPICの認証に相当するものへのサポートだ。
いくつかの機能はまた取り下げられている。これらにはBIO HTTPやBIO AJPコネクタを含む。 加えてComet supportもだ。これはWebSocketに大部分は取って代わられている。
Tomcat9へWebプロファイルを実装する計画はない。しかし、これはTomEEから提供される。
InfoQは今年のSpringOneのすべてのセッションを撮影している。ビデオはすべて今後数ヶ月中にサイトで視聴可能となる予定だ。
Rate this Article
- Editor Review
- Chief Editor Action