WebLogic Portal 8.1 へのアップグレード
|
 |
 |
|
この付録では、WebLogic Portal バージョン 8.1 から 8.1 SP5 までに行われた機能の変更について説明します。これらの変更はアップグレード後の環境に影響し、手動でタスクを実行しなければならない場合があります。
WebLogic Portal の新機能の詳細については、次の URL の『BEA WebLogic Platform 8.1 リリース ノート』を参照してください。
http://edocs.beasys.co.jp/e-docs/platform/docs81/relnotes/relnotes.html
WebLogic Portal 7.0 では、最小化されたポートレットの状態がデータベースに永続化されますが、WebLogic Portal 8.1 および各 Service Pack では、該当するセッションにのみ永続化されます。この節では、Service Pack 5 の WindowBackingContext に追加された次の新しい API メソッドに基づいてポートレットの状態をデータベースに永続化する方法を説明します。
public void setupStateChangeEventFromParent(String stateValue)
バッキング ファイルにあるこのメソッドを使用して、ポートレットの状態を親コントロール (デスクトップ、ブック、またはページ) から変更できます。このようにして、デスクトップ レベルの 1 つのバッキング ファイルで、そのデスクトップの下にあるすべてのポートレットの状態を制御できます。
BEA Web サイトの dev2dev ページで、このタスクを実行するバッキング ファイルがサンプルとして提供されています。この節で説明する実装は、サンプル バッキング ファイルに基づきます。このソリューション コードはバッキング ファイルとして提供されているので、アプリケーションの要件に応じて変更または更新できます。
この実装では、EntityPropertyManager を使用して、ポートレットの状態を PROPERTY_KEY テーブルと PROPERTY_VALUE テーブルに格納します。プロパティ名は、ポータル、デスクトップ、およびポートレットのラベルを使用して動的に設定され、状態を変更した各ユーザにマップされます。
サンプル バッキング ファイルを使用してポートレットの状態の永続化を設定するには、以下の手順に従います。
重要な注意 : この実装は、デフォルトで用意されている sample.portal を使用してテストされました。この実装ではログイン ポートレットの例を使用します。ログイン時に、バッキング ファイル内で handlePostbackData メソッドが呼び出され、URL に _nfpb=true が設定されます。別のログイン メカニズムを使用する場合は、ログイン後に最初にポータルが表示されるときに handlePostbackData が呼び出されるようにしてください。
バージョン 8.1 SP4 で、リクエスト永続性最適化の拡張により、ページ フローと Struts ポートレットの新しい属性が追加されました。この新しい requestAttrPersistence 属性により、アクションの実行直後にリクエストの状態を取り込むことができます。これにより、JSP はその状態に応じて、何度でも再表示することができ、ページの更新がサポートされます。
新しい属性のデフォルト値 session では既存の動作が保持されますが、新しい動作では、JSP 内でリクエストの状態を変更しようとすると機能しません。リクエストの状態を変更するロジックはすべて JSP の外に出し、アクションに移すことが理想的です。解決策としてあまりお勧めできませんが、リクエスト属性永続化の属性を none に設定すると、WebLogic Portal の自動永続化機能を無効にできます。
リクエスト属性永続化の属性の詳細については、次の URL にある WebLogic Workshop オンライン ヘルプを参照してください。
http://edocs.beasys.co.jp/e-docs/workshop/docs81/doc/ja_JP/portal/buildportals/portalPropertiesPortlet.html
WebLogic Portal SP6 では、url-template-config.xml ファイルの <generate-xml-amp-entity> 属性をオーバーライドする GenericURL クラスの新しいメソッドを使用できます。このメソッドは、URL のプログラム的な使用を可能にするために作成されました。
この新しい GenericURL.setForcedAmpForm(boolean) は、パブリック API を指定し、URL クエリ区切り文字を設定します。これにより、アンパサンド エンティティまたはアンパサンド文字の使用を決定するデフォルトのメカニズムがオーバーライドされます。true を渡すと、アンパサンド エンティティ (&) を使用した URL が生成され、false を渡すと、アンパサンド文字 (&) を使用した URL が生成されます。
次のコード フラグメントは、<generate-xml-amp-entity> 要素の true の値をオーバーライドする方法を示します。
PageURL postUrl = PageURL.createPageURL(getRequest(), getResponse());
postUrl.setPageLabel("Test_page_6");
postUrl.setForcedAmpForm(false);
postUrl.addParameter("test","test",true);
http://localhost:7001/test/test.portal?_nfpb=true&;_pageLabel=Test_page_6&test=test
この GenericURL JSP タグに対応する forcedAmpForm という属性も追加されました。この新しい属性が追加されたタグは次のとおりです。
render:windowUrlrender:standalonePortletUrlrender:pageUrlrender:postbackUrlrender:resourceUrlrender:toggleButtonUrlrender:jspContentUrl次のコード フラグメントは、上記の各 JSP タグのタグ ライブラリ定義の抜粋です。
<attribute
<name>forcedAmpForm</name>
<required>false</required>
<rtexprvalue>true</rtexprvalue>
<description>Forces the form of query separators used for this URL.
This overrides the natural mechanisms for determining ampersand entity
or character usage based on document type and/or configuration.
If the value 'true' is used, then "&" will be the separator.
If 'false' is used, then the "&" character will be the separator.</description>
</attribute>
Oracle Note 317258.1 にあるように、10g R2 バージョンの事前定義済みデータベース ロールの使用方法は、セキュリティ向上のために変更されました。現在、CONNECT ロールでは CREATE SESSION 権限のみが付与され、関連する他の権限は削除されました。
そのため、Oracle 10g R2 データベースには明示的に CREATE VIEW 権限を付与する必要があります。
WebLogic Portal 7.0 では、ポータル管理者は、ポートレットが特定のページにのみ表示されるように制限することができました。WebLogic Portal 8.1 では、ユーザが訪問者ツールを利用して、使用可能なすべてのページ上の、アクセス権限のあるポートレットを表示できるようになったため、この機能を直接使用することはできません。この節では、Service Pack 5 の PortalVisitorManager に追加された次の新しいメソッドに基づいてポートレットを特定のページに関連付ける方法を説明します。
public static String[] generateOnePortletCategoryArray(String webAppName, String pageLabel, String indentStr, HttpServletRequest request)
Service Pack 5 で新しく追加され、WebLogic Portal 7.0 のメソッドと同様の機能を実行するこのメソッドでは、ポートレット カテゴリおよび変更された訪問者ツールを使用します。管理者が、ポートレットを 1 つのカテゴリにまとめ、それをユニークなページ ラベルで関連付けます。その後で、訪問者ツールにより、ポートレット リストに適切なカテゴリのポートレットだけが含まれるようにフィルタされます。
注意 : この実装を使用するには、訪問者ツールのカスタマイズ機能を持つポータル内のすべてのページを 1 つのポートレット カテゴリに関連付けて、コードが個々のページのポートレットを見つけることができるようにする必要があります。
ポートレット カテゴリおよび変更された訪問者ツールを使用したコード例を、dev2dev Web サイト https://codesamples.projects.dev2dev.bea.com/servlets/Scarab?id=S174 で参照できます。
WebLogic Portal 7.0 では、ポータル管理者は、ユーザがカスタマイズすることによって特定のポートレットが削除されないように、ポータルを [必須] として設定できました。ただし、7.0 で [必須] フラグを使用した場合、ユーザが (たとえば) ポートレットをページ下部に移動することはできたため、ページをスクロールしないとポートレットが表示されない状態になることがありました。
WebLogic Portal 8.1 では、ページ上でのポートレットの位置を固定するために、プレースホルダのロックが導入されました (プレースホルダのロック機能の使用手順については、Administration Console オンライン ヘルプの http://edocs.beasys.co.jp/e-docs/wlp/docs81/adminportal/help/PM_PortletLock.html を参照してください)。
Web ページ上の特定位置に表示される必須ポートレットを作成するには、プレースホルダのロック機能とカスタム レイアウトを使用します。ページのレイアウトのカラムにプレースホルダをロックし、そのプレースホルダに必須ポートレットを配置します。カスタム レイアウトを使用して、この設定に必要なレイアウトを作成します。
次のホワイト ペーパーに、カスタム レイアウトの作成手順が記載されています。
http://edocs.beasys.co.jp/e-docs/wlp/docs81/whitepapers/netix/body.html
単純なプロデューサを WebLogic Portal Service Pack 3 から Service Pack 4 以降にアップグレードした場合、WSRP プロデューサ Web アプリケーション ライブラリは自動的に更新されません。SP3 から SP4 以降にアップグレードする場合、アップグレード後も単純なプロデューサが WSRP プロデューサとして正しく機能するように、以下の手順を実行する必要があります。
注意 : 単純なプロデューサは非ポータル Web アプリケーションです。単純なプロデューサの詳細については、『WebLogic Portal での WSRP の使用』の「プロデューサ」を参照してください。
BEAHOME/weblogic81/portal/lib/netuix/web/netui-adapter.jar
BEAHOME/weblogic81/portal/lib/netuix/system/ext/web/struts-adapter.jar
BEAHOME/weblogic81/portal/lib/netuix/system/ext/web/struts-adapter-html.tld
BEAHOME/weblogic81/portal/lib/netuix/system/ext/web/struts-adapter-naming.tld
BEAHOME/weblogic81/portal/lib/netuix/system/ext/web/struts-adapter-nested.tld
BEAHOME/weblogic81/portal/lib/netuix/system/ext/web/struts-adapter-tiles.tld
BEAHOME/weblogic81/portal/lib/wsrp/wsrp-producer.jar
BEAHOME/weblogic81/portal/lib/wsrp/adapters/wsrp-jpf-adapter.jar
BEAHOME/weblogic81/portal/lib/wsrp/adapters/wsrp-struts-adapter.jar
SP4 ではポータル フレームワークが変更され、パフォーマンスが著しく向上しています。これらの変更の多くは、WebLogic Portal の実装方法には影響しませんが、コントロール ツリーの状態管理機能が強化されたため、ポータルおよびデスクトップ内でセッション ID が重複しないように特に注意する必要があります。ID が重複しているとどのような影響があるかわかっていないため、問題が発生したときに診断が困難になります。
コンテンツ管理ポートレットは、cms_tools.jar ではなく wlp-admin.jar を使用するようになりました。以前の Service Pack で、プロジェクトにコンテンツ管理ポートレットを追加した場合、cms_tools.jar を削除し、SP4 バージョンの wlp-admin.jar を次のディレクトリに追加する必要があります。
<portal_application>¥<project>¥WEB-INF¥lib¥
SP4 バージョンの wlp-admin.jar は次のディレクトリにあります。
WL_HOME¥samples¥portal¥portalApp¥sampleportal¥WEB-INF¥lib
コンテンツ管理ポートレットの設定の詳細については、WebLogic Workshop オンライン ヘルプを参照してください。
WEB-INF¥url-template-config.xml ファイルはポータル Web プロジェクト内に自動的に作成されます。url-template-config.xml ファイルには、ユニークな名前を持つ複数の URL 「テンプレート」が含まれています。これらのテンプレートの URL には、url:domain や url:port などの変数が含まれ、これらはアクティブなサーバから読み込まれます。
以前の Service Pack の Web アプリケーションをアップグレードする場合は、以降の節で、url-template-config.xml ファイルの編集が必要かどうかを確認してください。
Administration Portal で新しいポータルを作成する場合、生成される url-template-config.xml ファイルには {url:currentPage} 変数が含まれません。ツリー最適化機能を使用し、[戻る] ボタンを完全に動作させるには、ファイルにこの変数を追加してください。
WSRP ポータル Web プロジェクトの url-template-config.xml ファイルには、リモート ポートレットの URL テンプレートと変数が含まれています。このファイルの各 WSRP URL テンプレートに次の 2 つの変更を加え、BEA 提供のコンシューマで BEA 以外のプロデューサのモード変更と状態変化を処理できるようにする必要があります。
Java ポートレット (JSR 168 ポートレット) を使用する場合は、url-template-config.xml ファイルを編集して次の例に示すように内容を追加または更新し、このファイルの SP4 バージョンの新しいコンテンツと一致するようにします。
<url-template name="portlet-secure-default">
https://{url:domain}:{url:securePort}/{url:path}?{url:queryString}{url:currentPage}
</url-template>
<!-- Map Java portlet URLs to the templates defined above.-->
<java-portlet-url-templates>
<url-template-ref type="action" name="portlet-action"/>
<url-template-ref type="secure-action" name="portlet-secure-action"/>
<url-template-ref type="resource" name="portlet-resource"/>
<url-template-ref type="secure-resource" name="portlet-secure-resource"/>
<url-template-ref type="render" name="portlet-default"/>
<url-template-ref type="secure-render" name="portlet-secure-default"/>
</java-portlet-url-templates>
Service Pack 4 より前は、サーバがバウンスまたは再デプロイされた場合は常に、.portlet ファイル内のプリファレンスがデータベース内のプリファレンスをオーバーライドし、管理者によるポートレット プリファレンスの追加および変更はサーバ再起動時に失われていました。
新しいオプションを使用すると、サーバ再起動時にポートレット プリファレンスを再ロードする方法を制御できます。このコントロールは、WEB-INF/netuix-config.xml ファイルで「propagate-preferences-on-deploy」要素の「master」属性を使用して実装します。
次の例は、属性の値を both に指定した要素を示しています。
<propagate-preferences-on-deploy propagate-to-instances="true" master="both"/> <reload-database-on-redeploy reload="false"/> </customization>
SP4 では、ポリシー参照 RDBMS 永続性機能のパフォーマンスが向上しました。以前の Service Pack からのアップグレードや、SP4 以前のドメインのアップグレードでは、p13nDataSource をルックアップするための新しい JNDI 名を追加する必要があります。
WebLogic Server コンソールでこのタスクを実行するには、次の手順に従います。
WebLogic Portal 8.1 SP4 では、資格データおよび委託管理のセキュリティ ポリシー参照データが新しいデータベース テーブルに格納されるようになりました。ポリシーは引き続き LDAP 内に格納されますが、ポリシー参照データは RDBMS に格納されます。アップグレードしたドメインの Administration Portal に最初にアクセスするときに、ポリシー参照データの移行がシステムによって自動的に実行されます。
データが新しいデータベース テーブルに移行されないようにするには、startWebLogic.cmd/.sh ファイルに以下の Java 環境パラメータを設定します。
-Dp13n.policyRef.LdapPersistence=Y
新しいデータベース テーブルの詳細については、『WebLogic Portal データベース管理ガイド』の「データ ディクショナリ」を参照してください。
http://edocs.beasys.co.jp/e-docs/wlp/docs81/db/4Schemas.html
WebLogic Portal 8.1 SP4 を起動すると、ロール値が自動的にキャッシュされます。通常は、この設定を変更する必要はありません。ただし、ロールの定義に、評価がリクエスト処理の過程で変化する式を使用する場合は、この設定を無効にする必要があります。
ロール キャッシングを無効にするには、該当アプリケーションの web.xml ファイルを編集します。このタスクの手順については、WebLogic Portal の『パフォーマンス チューニング ガイド』の http://edocs.beasys.co.jp/e-docs/wlp/docs81/perftune/4PortalApplication.html#1074386 を参照してください。
Service Pack 4 では、長期間アクティビティがない間も JDBC 接続をアクティブ状態に保つために、JDBC 接続プールが RDBMS 認証プロバイダに追加されました。これは、RDBMS 認証プロバイダの内部プーリング メカニズムによって使用される JDBC 接続が、ファイアウォールまたはデータベースによりタイムアウトすることを防ぐことを目的としています。
RDBMS 認証プロバイダのコンフィグレーション時に接続プールを有効にする必要があります。WebLogic Server コンソールには、プロバイダの作成時またはコンフィグレーション時に設定可能な以下の 2 つの新しい属性が含まれています。
ポータル プロジェクトは、ソース コントロール システムを使用して管理することをお勧めします。SP4 より前のリリースでは、クラス ファイルは WebLogic Workshop によってパス *WEB-INF/classes* に自動的にビルドされるため、このパスにはクラス ファイルを格納しないことが推奨されていました。しかし、SP4 では、パス *WEB-INF/classes/com/bea/jsptools/portal* に、以下の新しいクラスが追加されました。ソース ファイルは提供されません。
PortalManager.classPortalLogger.classPortalBeanManager.classPortalAdminLogger.classDefaultPortalLogger.classこの変更により、WebLogic Workshop に基づく SP4 のポータル プロジェクトは、ソース コントロール リポジトリから抽出される場合は正常にビルドされません。
ソース コントロールを使用した場合にポータル プロジェクトを正常にビルドできるようにするには、上記のクラス ファイルを含む .jar ファイルを作成し、その .jar ファイルをソース コントロール システムのリポジトリにチェックインします。
WebLogic Portal では、各プロキシ ポートレットを表示するために、数回のデータベース呼び出しを行ってプロキシ ポートレット情報を取得します。WebLogic Portal 8.1 SP6 には、proxyPortletCache という新しい p13n キャッシュが含まれており、この getProxyPortlet クエリの結果をキャッシュに保存できます。結合されたポータル (WSRP) を使用し、多数のプロキシ (リモート) ポートレットがある (環境ごとに異なりますが、たとえば 100 を超えるプロキシ ポートレットを実装している) 場合は、このキャッシュを使用することをお勧めします。
プロキシ ポートレット キャッシュの設定をカスタマイズするには、meta-inf/application-config.xml ファイルを編集し、次のエントリを追加します。
<Cache MaxEntries="max_number_of_proxy_portlets" Name="proxyPortletCache"
Notes="This caches the ProxyPortlets from getProxyPortlet query" TimeToLive="ttl_value"/>
max_number_of_proxy_portlets には 150 などの数値を入力します。
ttl_value にはタイムアウト値 (ミリ秒) を入力します。値 -1 を入力すると、キャッシュは期限切れになりません。
application-config.xml ファイルにこのエントリを追加したら、WebLogic Portal Administration Console を使用してキャッシュをコンフィグレーションまたはフラッシュできます。
ファイルにこのエントリを追加しない場合、キャッシュは Administration Console でコンフィグレーションできません。キャッシュは次のデフォルト値で使用されます。
注意 : プロキシ ポートレット キャッシュは、新しい Web アプリケーションでのみ自動的に使用されます。[ファイル｜Portal ライブラリの更新] を選択して既存の Web アプリケーションを更新しても、application-config.xml ファイルに必要なエントリを手動で追加しない限り、プロキシ ポートレット キャッシュは使用されません。
SP6 でコンテンツ クエリ式を実行するときに、優先順序が維持されず、式が正しく生成されません。式 (a && (b || c)) が、(a && b || c) として評価されます。
この問題は SP6 で修正でき、コンテンツ クエリ式の実行時に優先順序が維持されるようになります。8.1 SP5 以前と同様に式が評価されるように、システム プロパティが追加されました。コンテンツ クエリ式を正しく生成するには、次のように入力します。
WSRP 要求から次の WSRP 要求に、要求パラメータが暗黙的に伝播されなくなりました。この問題は、CR 254373 のパッチを適用している場合に影響します。すべてのプラットフォームが該当します。
CR254373 の修正を適用する前は、ポータル フレームワークにより、すべての要求パラメータが WSRP navigationState URL に自動的に追加されます。このアクションにより URL が大きくなりすぎるため、問題が発生していました。CR254373 によってこのバグは修正されましたが、修正の適用後にページフローが失敗するようになりました。ページフロー アクションにフォームを送信し、アクションが result.jsp に転送され、そこで要求からフォーム コンテンツを取り出して表示するといった手順が関連するページフローです。これは、標準のページフローでは機能しますが、フォームの送信とその後の結果の表示にはコンシューマからプロデューサへの 2 つの要求が必要 (ただし、ユーザがコンシューマと対話するときは 1 つの要求に見える) なので、WSRP コンシューマ ポートレットを介してページフローにアクセスすると失敗します。コンシューマからプロデューサへのフォームの送信は performBlockingInteraction() 呼び出しで処理されます。この呼び出しが完了すると、続いてコンシューマが getMarkup() 要求をプロデューサに送り、プロデューサは result.jsp ページのマークアップを返します。ただし、要求から次の要求へ要求パラメータが暗黙的に伝播されなくなったので、getMarkup() 要求の処理時にはフォーム パラメータは存在しません。前述のページフローは、この問題を表す一例ですが、performBlockingInteraction() 呼び出しが行われるすべてのケースに当てはまります。
これは解決策とはいえませんが、この機能を実装するための適切な方法です。必要なのは、要求に保持するパラメータを実装者が明示的に伝播することだけです。上記のページフローの例では、実装を修正できる簡単な解決策が 2 つあります。1 つ目の解決策は、送信されたフォームを受信したページフロー アクションが返す Forward オブジェクトにフォームを明示的に含めることで渡すことができます。これは、netui ActionForm オブジェクトを使用して指定できます。または、Forward オブジェクトに pageInput として個々のパラメータ名と値のペアを含めることができます。これで、results.jsp は、使用されるメソッドに適した方法で項目を取得します。もうひとつの解決策は、ページフローの状態の一部として目的のパラメータを保持することです。つまり、フォームを受信したアクションが、ページフローで ActionForm または要求から目的のパラメータを取得し、値をインスタンス変数に割り当て、ゲッターを使用してそれらの値にアクセスできるようにします。これで、result.jsp は、それらのゲッターを使用して必要な値にアクセスできます。
|
|
|