議論を呼ぶ Servlet 3.0の新機能

作者 Charles Humble , 翻訳者 渋川 よしき 投稿日 2008年6月3日

セクション

プロセス/プラクティス,

デベロップメント

トピック

JCP Standards ,

サーブレット ,

JCP ,

Java EE ,

Java ,

言語 ,

プログラミング ,

コミュニティ ,

Community

ほとんどのJavaのWebフレームワークはServlet API上に構築されている。1つないしは複数のサーブレットやフィルタ、リスナーを設定するには、WEB-INF/libディレクトリ内の依存関係を使うか、それに加えてアプリケーションのweb.xmという設定ファイルlを使用する必要がある。JSR-315ではServlet3.0の仕様を定めており、これはEE6の一部として含まれる計画になっている。この仕様では、この設定の部分が変更されるようである。この仕様書は現在早期ドラフト版であり、ダウンロードしてレビュー(source)することができる。

設定なしに接続可能にする、という目標を達成するために、この仕様では以下のような新しい仕様を提案している。

1. 追加アノテーション: Servlet 3.0仕様では@Servletを含むいくつかの新しいアノテーションが導入される。@Servletアノテーションは'@Servlet(url- mapping=”/foo”)'というような使い方をする。これを使用すると、URLマッピング情報を設定することができる。また、 @ServletFilterは@FilterMappingと連携してWebアプリケーション内のフィルタを定義するのに使用される。
   
2. web.xml フラグメントのサポート: このフラグメントにはサーブレット、フィルタ、リスナーの定義を含めることができる。このフラグメントはweb.xmlにマージされて、ウェブフレームワークのjarファイルにデフォルトとしてパッケージングすることができる。これにより、簡単に部品を取り替えて使用することができる。

フラグ(metadata-complete)はアノテーションとフラグメントの両方の情報取得のコントロールに使用される。

これらの機能を巡って、専門家グループの中では論争が起きている。ミスや、複雑な操作により、予期していないフィルタやサーブレットが配置されて、深刻なセキュリティリスクにつながるのではないか、と表明するメンバーもいる。また、この新機能が十分な柔軟性を備えているかどうかについても議論になっている。専門家グループはこれらについてコミュニティーのフィードバックを求めている。Greg Wilkins氏はこれらの懸案事項についてブログ(source)で説明してきた。この中では特にwebフラグメントの自動マージについて詳しく述べられ、３つあるソリューションのうちの１つの概要が書かれている。これはオプションのエレメントを使うことで、自動設定の制御を行うというものである。:

web.xml が存在しない場合と、が書かれていない3.0のweb.xmlが設定してある場合は、現在の案ではデフォルトの動作として WEB-INF以下のすべてのアノテーションのついたサーブレットとフィルタ、TLDリスナ、web.xmlフラグメントを探索します。エレメントが書かれたweb.xmlでは探索のプロセスが変更されます。以下がサンプルになります。:



このファイルの設定ではdwr.jar、cometd.jarのアノテーション、TLDフラグメント、web.xmlフラグメントが探索されます。また、 WEB-INF/classesディレクトリのアノテーションの設定されたサーブレットが探索されます。web.xmlのinclude設定に追加しない限り、これ以外のjarファイルやclassファイルが探索されることはありません。

Rajiv Mordani氏はこの仕様では満足していない(source)。

「もしもユーザの主な関心が、を書かないでサーブレットとフィルタを公開することにあるとしたら、Greg Wilkins氏の提案している手法のメリットはとても小さいということになります。私はこの問題はフレームワークの開発者には関係がありますが、意志を持って特定のコンポーネントだけ公開しようということをしないフレームワークのユーザには関係がないと思います。探索の仕方を制御するフラグを使うことで、部分探索した特定のjarファイルを除いて、インクルードメカニズムが提供するものすべてを利用することができます。スキャンするjarファイルのリストを書かなくてはならないので、インクルードメカニズムを使おうとすれば書くことが増えて冗長になります。

今年のJavaOneのカンファレンスでは、専門家のグループがこれ以外に２つの手法の可能性について議論を行った。一つ目の選択肢としては、webのフラグメントなどへの探索のon/offを制御するために、追加で二つめのフラグをmetadata-completeに導入するという方法である。これはアノテーションの役割と同様である。しかし、Rajiv Mordani氏が指摘するように、アノテーションメカニズムはweb.xmlを使用してオーバーライドでき、適切な管理階層を導入することができる。

アノテーションを使用してサーブレットとフィルタを宣言するときには、関連するサーブレットについたFilterMapping?アトリビュートと、 Filterを使ってurlマッピングをする必要があります。この方法を使うと厳密なマッピングをしないでサーブレットを公開する方法はありません。また、他のJava EEプラットフォーム、特にEJBやウェブサービスのような技術と同様に、配備記述子(deployment descriptor)を使用することで、アノテーションを使って定義された設定情報を上書きすることができます。もしアノテーションを使用しないで、配備記述子の定義のみを使用したい場合には、他のJava EE 5プラットフォームと同様に、配備記述子の中にmetadata-completeエレメントを入れる必要があります。このエレメントが存在し、"true"に設定されている場合には、アノテーションが評価されないで、記述子で定義された設定だけが使用されるようになります。こうすることで、自動探索は無効になり、パフォーマンスとセキュリティに対する心配は解消されます。

もう一つアプリケーションのweb.xml内のサーブレットとフィルタを無効にするための方法がある。以下のように、アプリケーションのメインのweb.xmlの中で、製品コードの環境ですべてのサーブレットが必要ではないという設定をするというものである。:

   <servlet> 
     <servlet-name>FrameworkServlet</servlet-name> 
     <enabled>false</enabled>  
   </servlet> 
   

フィードバックは jsr-315-comments at jcp.orgの専門家のグループの方で受け付けている。

原文はこちらです：http://www.infoq.com/news/2008/05/JSR-315