カテゴリー: Java

つづき・・・

PLT.6 Portlet Config

PortletConfigがイベント名前空間やレンダーパラメータ名などへもアクセスを提供するようだ。

PLT.6.3 Default Event Namespace

getDefaultNamespaceメソッドがポートレット配備記述子内のイベントとレンダーパラメータのデフォルト名前空間を返すとのこと。していされていなければ、XMLConstatns.NULL_NS_URIになる。これだけでは、用途がよく分からん。

PLT.6.4 Public Render Parameter Names

getPublicRenderParameterNamesはポートレット配備記述子内のポートレット定義にあるパブリックレンダーパラメータ名をかえすとのこと。指定されてなければ、空のEnumerationがかえる。

PLT.7.1 Portlet URLs

PortletURLとResourceURLインターフェースが存在する。ポートレットはどちらかのURLを生成する言になる。PortletResponseのcreateActionURL、createRenderURL、createResourceURLメソッドでそれらは作成される。

ResourceURLについては、出力ストリームでポートレットが完全に制御できて、バイナリマークアップも描画できる。ファイルアップロードように使用されないResourceURLはHTTPのGETメソッドでサーバー上の状態を変更しないものとして、アクセスできる。

PLT.7.1.1 BaseURL interface

BaseURLはポートレットへ差し戻す(?)すべてのURLで共通の方法であると言っている。うむむ、分かりにくい。ポートレットは、setParameterとsetParametersメソッドでアプリケーション固有のパラメータをBaseURLオブジェクトに追加できる。setParameterによって、前の同じな前のパラメータを差し替える。ポートレットがBaseURLに追加したパラメータは、リクエストパラメータとして、ポートレットで利用可能になる。ActionURLやRenderURLを作成したときに、現在のレンダーリクエストのパラメータは引き継がれないのに注意すべし。また、ResourceURLを作成した時には、現在のレンダーパラメータはポートレットコンテナーが自動的にURLに追加するので注意すべし(ただし、getParameter呼び出しからは隠されているとのこと)。

とりあえず、ここまで・・・。

PLT.5.4 Request Handling

ここは、いつものことながら、ポートレットの処理を理解する上で大切なところね。ポートレットは、従来通り、processActionとrenderメソッドがあり、それに加えて、processEventとserveResourceメソッドがライフサイクルにあるということ。流れとしては、processActionが呼ばれて、そこで、１つ以上のイベントを発行してもいいし、イベントがあれば、対象の他のポートレットでprocessEventが呼ばれることになる。あとは、renderメソッドのときは、render のリクエストだし、serveResourceメソッドのときは、resource のリクエストを参照する。

PortletURL は、今まで、Action URL、Render URLに加えて、Resource URLがあるそうな。

まず、通常のアクションが呼ばれる流れを見ると(ActionURLの場合)、1つのAction Request(processAction)が処理され、0個以上のEvent Request(processEvent)が呼ばれ、1つ以上のRender Request(render)が呼ばれる。何個のrenderが呼ばれるかは、ページにあるポートレットの数に依存。renderメソッド後に、Resource Request(serveResouce)の処理がある。processAction->processEvent->renderの呼ばれる順番は崩れることはなく、それぞれが終わったら、次に移る。renderのメソッドは、複数同時に(パラレルに)実行してもOK(processEventはパラレルに実行していいのかは書いてない)。

RenderURLの場合、renderメソッドが呼ばれて、renderの内容によってserveResource。この場合は、processActionなどの他のライフサイクルメソッドは呼ばれない(といっても、processActionとprocessEventが呼ばないと言っているだけだね)。

ResourceURLの場合は、対象のポートレットのserveResourceメソッドが呼ばれる。

PLT.5.4.1 Action Request

ActionResponseのsetEventメソッドで、イベントを発行していいよっと言っている。

PLT.5.4.2 Event Request

processEventはEventRequestとEventResponseを持つと言っている。EventRequestは、ウィンドウ状態、ポートレットモード、現在のレンダーパラメータ、ポートレットコンテキスト、ポートレットセッション、ポートレットプリファレンスにアクセスできるそうな。ポートレットモードとウィンドウ状態を変えるなら、EventResponseでとのこと。また、EventResponseでは、レンダーパラメータを変更しても良くて、また、setEventを発行可と言っている。うーん、イベントでイベントを発行できるのは便利そうだけど、ややこしそうだな・・・。

PLT.5.4.4 Resource Request

ポートレット経由でリソースを供給したり、コンテンツの断片を描画するために、ResourceServingPortletインターフェースを実装する。Resource URL でそのインターフェースの serveResourceメソッドが呼ばれる。このメソッドは、ResourceRequestとResourceResponseを持っている。

ResourceRequestはそのリクエストのパラメータ、入力ストリーム、ウィンドウ状態、ポートレットモード、ポータルコンテキスト、ポートレットセッション、ポートレットプリファレンスにアクセス可能。そして、ResourceResponseのライターか出力ストリームで吐き出す。吐き出し方は、ServletやJSPに渡すことも可能。細かいことは、PLT.13を見ろといっている。

PLT.5.4.5.1 Action Dispatching

processActionにアノテーションという話が出ている。新しい話だな。@ProcessAction(name=<action name>)で、ActionURLにjavax.portlet.action(またはActionRequest.ACTION_NAME)で渡すとのことだ。メソッドは、

void <methodname> (ActionRequest, ActionResponse) throws PortletException,
java.io.IOException;

とするようだ。なるほど、確かに、今まで、素のポートレットAPIでポートレットを作ると、processActionで振り分けは面倒だったからな・・・。

PLT.5.4.5.2 Event Dispatching

これも、@ProcessEventのアノテーションがある。いまいち、イベントの使い方の説明を見ていないので、詳細が分かってないけど、@ProcessEvent(qname=<event name>)と、ロカールパートだけ指定する@ProcessEvent(name=<event name_local_part>)があるようだ。前者のものは、”{“+Namespace URI+”}”+local partというフォーマットになるみたい。メソッドは

void <methodname> (EventRequest, EventResponse) throws
PortletException, java.io.IOException;

という形。

PLT.5.4.5.3 Resource Serving Dispatching

リソースIDという話が出てきている。これだけ読んでも詳細不明。リソースIDがなければ、serveResourceは何もしないといっている。

PLT.5.4.5.4 Rendering Dispatching

これも、@RenderMode(name=<portlet mode name>)のアノテーションが導入。メソッドは、

void <methodname> (RenderRequest, RenderResponse) throws
PortletException, java.io.IOException;

の形。

PLT.5.4.6 Multithreading Issues During Request Handling

processAction、render、processEvent、servResourceはconcurrentにするべし。

PLT.5.4.7 Exceptions During Request Handling

PortletExceptionがprocessActionやprocessEventで発生したら、ActionResponseへの操作はすべて無視するとのこと。その他の例外は従来どおりの動き。

PLT.5.4.8 Thread Safety

RequestとResponseのオブジェクトについては、スレッドセーフを保証しない。これらは、processAction、processEvent、serveResource、renderでよばれるだけなので。

アノテーションの話は新しいことだな・・・。

とりあえず、ここまで・・・。

PLT.3 Relationship with the Servlet Specification

EventやResource関連が追加されたので、その影響による文の変更かね。ポートレットはserveResourceを通して、リソースを描画するときにレスポンスをフルコントロールできるといっている(何となくイメージは分かるが、詳細を見ないと何とも言えないな。たぶん、ResourceURLで返すリソースのレスポンスの話の気がするけど)。

PLT.4.3 Portlets and Web Frameworks

2.0 からprocessAction、processEvent、render、serveResourceと処理でよばれるのが増えているので、個人的には、他のフレームワークでどうするのかが気になっている(Teedaをどう対応させていくかとか・・・)。この節では、2.0ではフレームワークへのブリッジを簡単に実装する追加手段を用意すると書いてあるけど、何を意味するのだろうか・・・(後述なの??)。

PLT. 5The Portlet Interface and Additional Life Cycle Interfaces

Eventを受け取ったり送ったりするインターフェースとしてEventPortlet、リソースを供給するインターフェースとしてResourceServingPortletが追加されたといっている。これに伴い、GenericPortletは、Portlet、EventPortlet、ResourceServingPortletのインターフェースを実装したとのこと。

PLT.5.2 Portlet Life Cycle

EventPortletとResourceServingPortletが追加の省略可能なライフサイクルだといっている。

PLT.5.2.2.1 Error Conditions on Initialization

これは従来どおりの話なのだけど、initでUnavailabeExceptionを投げるときに時間を指定しておけば、再度、initを呼びにいってもいいのね。前に呼んだときは、気にも留めなかったけど、近頃、initでPortletExceptionを投げるコードもよく書くので、気になっただけ。

PLT.5.2.3 End of Service

destroyメソッドを呼ぶ話。destoryを呼ぶ前にポートレットオブジェクトのリクエスト処理を完了させるとか、リクエスト処理完了を永久に待ち続けると困るから、タイムアウトを設定可能とか、destoryでRuntimeExceptionが発生しても、destoryは完了したとみなすとかかな。まぁ、その他に書いてあることは、その名の通り、destory ですということ。あ、でも、よく見たら、この節は1.0にもあった。

PLT.5.3.1 Portlet Definition and Portlet Entity

別に新しい話ではない気がする。単にPortletPreferencesについて、改めて、言っているだけかな。まぁ、管理ツールなどをポータルが提供してもいいよ、という感じのことを言っているだけかな。

PLT.5.3.2 Portlet Window

ポートレットのウィンドウIDは、PortletRequest.getWindowId()で取得可能といっている。ポートレットスコープのセッションとかは、こいつがキーとして使われる(実際には、キーにウィンドウIDが付加される形だと思うけど)。あとは、ウィンドウIDは?を含まないと書いてある(PLT.17.3を見ろとかいてある)。

とりあえず、ここまで・・・。まだ先は長し・・・。