Tomcatでのポータルのクラスタのお話。メモ。クロスコンテキストのセッションレプリケーションって、めんどう・・・。
http://issues.apache.org/bugzilla/show_bug.cgi?id=35710
http://www.ja-sig.org/wiki/display/PLT/Clustering+JSR-168+Portlet+Applications+in+Tomcat
Challange IT For Future
Tomcatでのポータルのクラスタのお話。メモ。クロスコンテキストのセッションレプリケーションって、めんどう・・・。
http://issues.apache.org/bugzilla/show_bug.cgi?id=35710
http://www.ja-sig.org/wiki/display/PLT/Clustering+JSR-168+Portlet+Applications+in+Tomcat
つづき・・・
URLにベンダ固有の情報を設定するために、ポートレットで利用可能なプロパティがある。BaseURLのsetPropertyとaddPropertyでそれが可能で、setProperty で名前と値を渡して設定して、再度、setPropertyをすれば、上書きされる。addPropertyはあたえられた名前に値を追加する。
ちょっとここは変更が入っている。ポートレットがポータルが管理していないモードを追加してよいとある。ポータルによって管理されないモードは、portal-maangedタグをfalseとして宣言するそうな。
ポートレットは、カスタムポートレットモードを利用するポートレット配備記述子にcustom-portlet-mode要素で定義する。配備時に、ポータルで管理されているモードは、ポータルに実装されるモードにマップされる。一方、ポータルに管理されないモードを藻津ポートレットは、カスタムポートレットモードセクションのdecoration-name要素のテキストとして提供される。このテキストは、リソースバンドルで翻訳可で、リソースバンドルがなければ、decoration-nameタグで提供された名前をそのままモード名として利用することになる。まぁ、別にそこまでしなくてもサポートしないモードとして、放置でもいいみたい。
以下が例。
<portlet-app> ... <custom-portlet-mode> <description>Creates content for Cut and Paste</description> <portlet-mode>clipboard</portlet-mode> <portal-managed>false</portal-managed> <decoration-idname>ClipboardMode</decorationidname> </custom-portlet-mode> <custom-portlet-mode> <description>Provides administration functions</description> <portlet-mode>configadmin</portlet-mode> <portal-managed>true</portal-managed> </custom-portlet-mode> ... </portlet-app>
というわけで、decoration-nameとportal-managedが新登場。
renderメソッドもアノテーションがサポートされている。@RenderMode(name=<portlet mode name>)という感じ。メソッドは、
void <methodname> (RenderRequest, RenderResponse) throws PortletException, java.io.IOException;
という感じ。GenericPortletで特にマッチするのがなければ、doView, doEdit, doHelpが呼ばれる。
どうやら、表示する際に、その表示したときの状態に対して、選択できるポートレットモードを指定できるらしい。指定しなければ、従来通り、ポートレット配備記述子に書いたものが全部表示される。javax.portlet.renderHeaders(これはいまいち謎?)を指定できるか、GenericPortletのgetNextPossiblePortletModesを上書きしても良いし、setNextPossiblePortletModesでRENDER_HEADERS内にセットも可能らしい(PLT.11.1.1.3.3を見るべし)
とりあえず、ここまで・・・。
つづき・・・
PortletConfigがイベント名前空間やレンダーパラメータ名などへもアクセスを提供するようだ。
getDefaultNamespaceメソッドがポートレット配備記述子内のイベントとレンダーパラメータのデフォルト名前空間を返すとのこと。していされていなければ、XMLConstatns.NULL_NS_URIになる。これだけでは、用途がよく分からん。
getPublicRenderParameterNamesはポートレット配備記述子内のポートレット定義にあるパブリックレンダーパラメータ名をかえすとのこと。指定されてなければ、空のEnumerationがかえる。
PortletURLとResourceURLインターフェースが存在する。ポートレットはどちらかのURLを生成する言になる。PortletResponseのcreateActionURL、createRenderURL、createResourceURLメソッドでそれらは作成される。
ResourceURLについては、出力ストリームでポートレットが完全に制御できて、バイナリマークアップも描画できる。ファイルアップロードように使用されないResourceURLはHTTPのGETメソッドでサーバー上の状態を変更しないものとして、アクセスできる。
BaseURLはポートレットへ差し戻す(?)すべてのURLで共通の方法であると言っている。うむむ、分かりにくい。ポートレットは、setParameterとsetParametersメソッドでアプリケーション固有のパラメータをBaseURLオブジェクトに追加できる。setParameterによって、前の同じな前のパラメータを差し替える。ポートレットがBaseURLに追加したパラメータは、リクエストパラメータとして、ポートレットで利用可能になる。ActionURLやRenderURLを作成したときに、現在のレンダーリクエストのパラメータは引き継がれないのに注意すべし。また、ResourceURLを作成した時には、現在のレンダーパラメータはポートレットコンテナーが自動的にURLに追加するので注意すべし(ただし、getParameter呼び出しからは隠されているとのこと)。
とりあえず、ここまで・・・。