|
|
この付録では、WebLogic Portal バージョン 9.2 とバージョン 9.2 MP1 で行われた機能の変更について説明します。これらの変更はアップグレード後の環境に影響し、手動でタスクを実行しなければならない場合があります。
WLP 9.2 MP1 では、次の機能変更が導入されています。
9.2 MP1 に付属のドメイン アップグレード ツールでは、既存の config.xml ファイルを使用して、適切なすべての製品ライブラリ モジュールの実装バージョンを更新します。ツールを実行する時期や方法については、「Maintenance Pack へのドメインのアップグレード」を参照してください。
GroupSpace のリッチ テキスト コンテンツはクロスサイト スクリプティング (XSS) 攻撃を受けやすくなります。これは、GroupSpace のリッチ テキスト コンテンツが実際は HTML であるため、HTML が表示されるときに他のユーザのブラウザで実行する JavaScript コードを追加できるためです。ユーザのブラウザをリダイレクトする操作を実行するなど、JavaScript に悪意のあるコードが含まれることが考えられます。GroupSpace のリッチ テキスト コンテンツの例には、GroupNote の本体フィールドや Issue のメモ フィールドなどがあります。
WebLogic Portal 9.2 MP1 では、リッチ テキストの編集は管理者が web.xml ファイルを通じて管理し、それに応じて、ポータル開発のユーザ インタフェースにリッチ テキストと HTML 編集のためのオプションが示されます。
web.xml で com.bea.apps.groupspace.RichTextEditorEnabled パラメータが「true」に設定されている場合は、ポートレット プリファレンス RichTextEditorEnabled に基づいてリッチテキスト エディタが使用可能になる。com.bea.apps.groupspace.RichTextEditorEnabled パラメータが設定されていない場合、または「true」以外の値に設定されている場合は、ポートレット プリファレンスは考慮されず、リッチテキスト エディタは使用できません。このパラメータの値が「true」である場合に、ポートレット プリファレンスによってエディタが使用可能であるかどうかが決定されます。 web.xml 内の別のパラメータ com.bea.apps.pgroupspace.RichTextEditorHTMLToolBarEnabled およびポートレット プリファレンス RichTextEditorHTMLToolBarEnabled によって、HTML の直接入力が可能であるかどうかが制御される。web.xml のパラメータが true に設定され、ポートレット プリファレンスが有効である場合、UI に HTML オプションが表示され、リッチテキスト エディタで HTML コンテンツを入力できるようになります。web.xml で collaboration.RichTextEditorEnabled パラメータが「true」に設定されている場合、ポートレット プリファレンス collaboration.rich_text.enabled に基づいてリッチテキスト エディタが使用可能になる。web.xml でパラメータが設定されていない場合、または「true」以外の値に設定されている場合は、ポートレット プリファレンスは考慮されず、リッチテキスト エディタは使用できません。このパラメータの値が「true」である場合に、ポートレット プリファレンスによってエディタが使用可能であるかどうかが決定されます。
この節では、リッチテキスト エディタと HTML 入力の可用性に関連するデフォルト設定について説明します。
初期状態の GroupSpace サンプルの場合は、リッチテキスト エディタが有効になります。その他のすべての Web プロジェクトの場合、デフォルトではリッチテキスト エディタがポートレットに対して無効な状態です (GroupSpace またはコラボレーション)。管理者は、セキュリティ上のリスクを考慮しながら、この設定を変更できます。
以下の設定を持つ Web アプリケーションには、web.xml の断片が含まれます。
com.bea.apps.groupspace.RichTextEditorEnabled = "true"
collaboration.RichTextEditorEnabled = "true"
com.bea.apps.groupspace.RichTextEditorHTMLToolBarEnabled = "true"
| 注意 : | WebLogic Workshop で顧客が作成した Web プロジェクトには上記のパラメータが含まれないため、デフォルトではリッチテキスト エディタが無効になります。 |
GroupSpace (GroupNote、問題、通知、通知の表示) の場合、RichTextEditorEnabled のポートレット プリファレンスは「true」であり、RichTextEditorHTMLToolBarEnabled のポートレット プリファレンスは「false」です。
開発者が作成したプロジェクトの場合、web.xml には以下の値が含まれます。
com.bea.apps.groupspace.RichTextEditorEnabled = NOT SET
collaboration.RichTextEditorEnabled = NOT SET
com.bea.apps.groupspace.RichTextEditorHTMLToolBarEnabled = NOT SET
| 注意 : | NOT SET は「false」を意味します。 |
GroupSpace の場合、RichTextEditorEnabled のポートレット プリファレンスは「true」であり、RichTextEditorHTMLToolBarEnabled のポートレット プリファレンスは「false」です。
コラボレーション ポートレットの場合、collaboration.RichTextEditorEnabled のポートレット プリファレンスは「true」であり、HTML 編集を行うことはできません。
| 注意: |
| 注意 : | web.xml のパラメータの設定値を変更する場合は、Web アプリケーションを再デプロイして変更内容を有効にする必要があります。 |
| 注意 : | ポータル プリファレンスの値はページフローにキャッシュされます。したがって、Admin Portal でプリファレンス値を変更した後で、GroupSpace からログアウトし、ログインし直して新しいプリファレンス値の影響を確認する必要があります。 |
| 注意 : | web.xml およびポートレット プリファレンスでのこれらの設定は、切り替えて使用することを前提としていません。リッチテキスト エディタの使用方法をデプロイメント時に指定し、GroupSpace インスタンスを使用する前にこれらの設定を行っておく必要があります。リッチテキスト エディタでコンテンツを作成してからエディタを無効にすると、コンテンツが正しく表示されない場合があります。 |
| 注意 : | たとえば、リッチテキスト エディタでコンテンツを作成または編集する場合、改行が <br> タグで表されます。しかし、リッチテキスト エディタが無効な場合、改行は挿入されずに、単に「<br>」として表示されます。 |
ResourceProxyServlet は、取得する静的リソースから Set-Cookie をブラウザに送り返します。この Set-Cookie はプロデューサから取得され、ブラウザ内にすでに存在する、コンシューマ セッションを示す Set-Cookie を上書きします。したがって、次の要求をブラウザから受信すると、このセッションは失われます。通常、CookiePath の設定によって Set-Cookie が区別されると、この問題は解決します。この処理ができない場合 (同じドメインにシングル サインオンを実装する場合など)、問題は解決しません。
この問題は解決され、セッションが失われないようにするための新しいシステム プロパティが導入されました。システム プロパティ wlp.resource.proxy.servlet.block.response.headers を有効にすると、ResourceProxyServlet がブラウザに Set-Cookie ヘッダを送り返すのをブロックします。
これにより、両方のアプリケーションで同じクッキー名を使用できます (SSO で必要な場合)。また、リソースが返されたときに、ブラウザでコンシューマのクッキーがプロデューサのクッキーによって上書きされることはありません。
システム プロパティの設定の詳細については、「セッション クッキーのコンフィグレーション」 (http://edocs.beasys.co.jp/e-docs/wlp/docs92/federation/Chap-Best_Practices.html) を参照してください。
WLP 9.2 GA では、次の機能変更が導入されています。
WebLogic Portal 8.1 から UUP をアップグレードする場合は、p13n_ejb.jar ファイルが削除され、新しい WebLogic Portal 9.2 バージョンのファイルに置き換えられます。新しい p13n_ejb.jar ファイルは、WebLogic Portal 9.2 に付属のライブラリ モジュールにパッケージ化されます。
次の手順を実行して、WebLogic Portal 8.1 でコンフィグレーションされた UUP を WebLogic Portal 9.2 の UUP にアップグレードします。
.work ファイルを選択し、[開く] をクリックします。UUP アプリケーションのチェック ボックスが選択されていることを確認し、[次へ] をクリックします。画面は図 A-1 のようになります。
p13n-ejb.jar ファイルが削除されている。UUPExample.jar) が存在する。<UUPApplication>/EARContent/META-INF/ ディレクトリ内の application.xml ファイルのモジュール エントリで参照される。<UUPApplication>/EARContent/META-INF/ ディレクトリの p13n-cache-config.xml ファイルに次のキャッシュ エントリが追加された。<p13n:cache>
<p13n:name>UUPExampleCache</p13n:name>
<p13n:description>Cache for UUP Example</p13n:description>
<p13n:time-to-live>60000</p13n:time-to-live>
<p13n:max-entries>100</p13n:max-entries>
</p13n:cache>data/src/userprofiles/ ディレクトリ (または Datasync フォルダが存在するディレクトリ) にユーザ プロファイル ファイル (たとえば、UUPExample.usr) が存在することを確認する。
WebLogic Portal 8.1 Java プロジェクトが存在し、それを Portal 9.2 にアップグレードする場合は、[インポート] ウィザードによってユーティリティ プロジェクトが自動作成されます。ユーティリティ プロジェクトは、直接的に特別なエンティティ (Web サービス、コントロール、EJB など) の一部にはならない汎用的な Java コードの作成に使用されます。ユーティリティ プロジェクトの作成手順については、『ポータル開発ガイド』を参照してください。
表 A -1 は、アップグレード後にユーティリティ プロジェクトに追加する一般的な WebLogic Portal J2EE ライブラリの一部を示しています。
詳細については、『ポータル開発ガイド』を参照してください。
Autonomy 検索を使用して、WebLogic Portal 8.1 からアップグレードする場合は、次の手順を実行して WebLogic Portal 9.2 に含まれている新バージョンの Autonomy にアップグレードする必要があります。アップグレード処理は、自動的に既存の検索設定とデータベースを新しい検索機能に移動しません。アップグレードしたアプリケーションで Autonomy 検索を操作するには、手動でコンフィグレーションする必要があります。
新しいバージョンの Autonomy は、portal/thirdparty/autonomy-wlp92 ディレクトリにインストールされます。Autonomy 検索コンフィグレーションの詳細については、『WebLogic Portal の検索ガイド』を参照してください。
Autonomy 検索のインストールとコンフィグレーションが終了したら、新しい機能を使用できるように、次の手順を実行してアプリケーションをアップグレードします。
WebLogic Portal com.bea.query クラスまたは 8.1 Autonomy API を使用してアプリケーションを記述し、新しい 9.2 バージョンの Autonomy API を使用しないでこれらのアプリケーションを引き続き使用する場合、古い非推奨 API をアプリケーションに手動で追加する必要があります。
ただし、WebLogic Portal または Autonomy の 8.1 API を引き続き使用する場合、8.1 API が 9.2 API より優先され、9.2 Autonomy エンジンとの互換性がなくなります。つまり、全文検索など、9.2 の一部のコンテンツ管理機能を使用できません。
8.1 バージョンの Autonomy をポータル アプリケーションで引き続き使用する場合、古い API をインストールに手動で追加する必要があります。
古いバージョンの Autonomy を 9.2 アプリケーションに追加するには
autonomyCompat.jar と autonomyClient.1.5.0.jar を weblogic_home/portal/lib/thirdparty/search/81-compat-only ディレクトリから application_home/APP-INF/lib ディレクトリにコピーします。
バージョン 8.1 の Autonomy API とエンジンが実行されます。
「9.2 ポータル アプリケーションにおける 8.1 検索の使用」の手順を完了した後に 9.2 バージョンの Autonomy にアップグレードする場合、実装を元に戻すことができます。
9.2 で 8.1 Autonomy を実装した後に 9.2 バージョンの Autonomy を使用するようにアップグレードするには
com.bea.query.* クラスの使用またはアプリケーションの Autonomy クライアント API への呼び出しを探し、更新し、それらを 9.2 バージョンの Autonomy API への適切な呼び出しに置き換えます。autonomyCompat.jar ファイルと autonomyClient1.5.0.jar ファイルを app-inf/lib ディレクトリから削除します。
アップグレードが完了したら、Administration Console を使用してサードパーティのリポジトリのパスワードを手動で再入力します。リポジトリ設定の編集については、『コンテンツ管理ガイド』を参照してください。
サードパーティのリポジトリのパスワードを手動で再入力するまで、それらのリポジトリにはアクセスできません。
WebLogic 8.1 から WebLogic Portal 8.1 SP5 まででは、優先順位の問題によりコンテンツ クエリ式の生成が異なっていました。コンテンツ クエリ式の実行時に優先順位が保持されませんでした。たとえば、(a && (b || c) という式は (a && b || c) として評価され、実行されます。
この問題は 9.2 では修正され、現在ではコンテンツ クエリ式を実行した場合に優先順位が保持されるようになりました。ただし、WebLogic Portal 8.1 から WebLogic Portal SP5 までのクエリ動作を引き続き使用する場合、ドメイン スクリプトを変更して次のシステム プロパティを定義する必要があります。-Dwlp.disable.content.rule.fix=true.
WebLogic Portal 8.1 では、ポータルのルック アンド フィールに対して、skin.properties (/skins/<skin_name> ディレクトリ) と skeleton.properties (/skeletons/<skeleton_name> ディレクトリ) という 2 つのコンフィグレーション ファイルを使用していました。どちらもテキスト ファイルで、skeleton.properties は任意でした。
WebLogic Portal 9.2 では、どちらのファイルも XML ファイルで、必須になりました。
WebLogic Portal 8.1 のルック アンド フィールを WebLogic Portal 9.2 形式にアップグレードするには、次の作業を行います。
cm_taglib.jar は、WebLogic Portal 7.0 ベース DocumentManager 機能用のタグ ライブラリです。[インポート] ウィザードでは、この taglib (サポートされない taglib UR を持つ) を参照する JSP があるかどうかが検出されません。JSP は失敗します。
デフォルトでは、cm_taglib.jar ファイルは新しい 8.1 Web アプリケーションにインストールされませんでした。ただし、下位互換性のためにそのファイルを追加した場合は、アップグレードしたアプリケーションでこのファイルを手動で処理する必要があります。
サポートされるタグと API を使用するように、cm_taglib.jar へのすべての参照を変更し、ファイル cm_taglib.jar を削除します。
バージョン 9.2 では、Struts 1.2 にアップグレードした場合、Struts に対する WebLogic Portal サポートが多少異なります。
WebLogic Portal の Struts 1.1 サポートは以前のリリースと同じであり、web.xml を使用して struts-adapter taglib が URI にマップされます。新しい struts-1.2.war ライブラリ モジュールの代わりに、struts-1.1.war ライブラリ モジュールを使用できます。
web.xml を使用して struts と struts-adapter taglib をマップするのではなく、Struts 1.2 にアップグレードすると、現在 WebLogic Portal は JSP 1.2 の暗黙的な taglib マッピングを使用しているため、Web コンテナによって JAR の META-INF ディレクトリにある .tld ファイルが tld に指定した URI に暗黙的にマップされます。WebLogic Portal では、これらはパス META-inf/tlds の struts-adapter.jar にあります。
Struts 1.2 にアップグレードするには、次の 2 種類の方法のいずれかを選択します。
http://bea.com/struts/adapter/tags-html を、ネストされた taglib の場合は http://bea.com/struts/adapter/tags-nested を、アダプタがオーバーライドしない他の taglib の場合は http://struts.apache.org/tags-* を参照する struts taglib を使用する。struts.jar (struts-1.1.war 内) と struts-adapter.jar (ポータル Web ライブラリ モジュール内) の両方から .tld を抽出し、WEB-INF/tlds にコピーする。これにより、web.xml を使用した明示的 tld マッピングを引き続き使用できます。
バージョン 8.1 には定義ラベルを編集する機能が用意されていましたが、非推奨でした。定義ラベルを変更すると、保護されたリソースをエクスポーズしたり、ポートレット ハンドルとして定義ラベルを使用する WSRP を壊すなど、意図しない影響を及ぼすことがありました。
バージョン 9.2 ではこの機能が置き換えられ、ユーザ カスタマイズを失ったり、ラベルを変更することなく、プロダクション環境と開発環境の間でポータル リソース (ブック、ページ、デスクトップ) を移動することができます。この新しい機能には XIP と Propagation Utility が含まれています。XIP では個別のポータル リソースを開発システムとプロダクション システム間でインポートおよびエクスポートでき、スコープ (ライブラリ、管理、または訪問者) を指定できます。WebLogic Portal の伝播ツールについては、『プロダクション業務ガイド』を参照してください。
WebLogic Portal 8.1 では、セッション用に最小限のポートレット状態が永続化されていました。解決策として、『WebLogic Portal 8.1 へのアップグレード』で記載されているように、デスクトップのポートレットの状態を制御するバッキング ファイルを設定できます。
バージョン 8.1 で使用した解決策に依存している場合はその方法を継続できますが、ポートレットの状態を永続化する新しい方法を使用することをお勧めします。
バージョン 9.2 でデータベースのポートレットの状態を永続化するには、netuix-config.xml ファイルの control-state-location 要素にある persistence-enabled 属性を使用します。
persistence-enabled 属性の例を次に示します。
<session persistence-enabled="true"/>
persistence-enabled 属性を true に設定すると、ユーザがログインしたときにコントロール ツリーの状態がデータベースからロードされ、ユーザがログアウトしたときに新しい状態が保存されます。コントロール ツリーの状態は、ユーザがポータルと対話したときに消去されます。
実装されているデフォルトかつ唯一の永続性タイプは JDBC です。デフォルトの実装では、ユーザの ProfileWrapper の BEA_PORTAL_FRAMEWORK_CONTROL_TREE_STATE プロパティ セットを使用します。ProfileWrapper はユーザの HTTP セッションで作成され、保存されている必要があります。ProfileWrapper は、web.xml ファイルでコンフィグレーションされる PortalServletFilter によって作成されます。ProfileWrapper がユーザのセッションに見つからないと、コントロール ツリーの状態は永続化されません。
| 注意 : | ページ フローと struts に関連する状態は、コントロール ツリーの状態の一部ではないため、永続化されません。ページ フローのポートレットと struts のポートレットは、ユーザがログアウトしたときと同じ状態ではない可能性があります。 |
子要素の reader-class-name はこの state-location のリーダー クラス名を、writer-class-name はライター クラス名を指定します。リーダーまたはライターの動作をカスタマイズするには、ControlStateReader インタフェースまたは ControlStateWriter インタフェースを実装し、netuix-config.xml ファイルでインタフェースをコンフィグレーションします。
Weblogic Portal. 9.2 を使用して開発されたプロデューサ アプリケーションとコンシューマ アプリケーションは、WebLogic Portal 8.1 を使用して開発されたプロデューサおよびコンシューマと互換性があります。つまり、Weblogic Portal. 9.2 を使用して開発されたポータルには、WebLogic Portal 8.1 ドメインでデプロイされたポートレットを使用できます。同じように、WebLogic Portal 9.2 プロデューサでエクスポーズしたポートレットは、8.1 コンシューマによって使用できます。
ただし、8.1 コンシューマまたは 9.2 コンシューマに対して独自のキーを使用する場合は、『連合ポータル ガイド』の「SAML による WSRP セキュリティの確立」の手順に従う必要があります。
この節では、HTTP 応答のエンコーディング設定の変更について説明します。
バージョン 8.1 の WebLogic Portal では、次のエンコーディング設定方法が使用されていました。
バージョン 9.2 の WebLogic Portal では、次のエンコーディング設定方法が使用されます。
古い方法も引き続き使用できますが、非推奨の警告を発生させないように、新しい方法を使用することをお勧めします。次に例を示します。
.portalファイルの<netuix:desktop ... encoding="UTF-8" />
netuix-config.xmlファイルの<defaultEncoding encoding="UTF-8" />
.portal ファイルを編集中にポータル ビューまたはアウトライン ビューからデスクトップ要素を選択すると、ワークベンチではプロパティ ビューに新しい encoding プロパティが表示されるようになりました。新しいポータルのデフォルト値は UTF-8 です。値を編集するには、編集可能なドロップダウン メニューを使用します。
最初は、ドロップダウン メニューにはすべての基本的な IANA エンコーディング値に加えて中国語、韓国語、および日本語用の拡張エンコーディングのリストが表示されます。リストに表示される値は説明用の表示名であり、.portal ファイルに保存されるときに実際の IANA 名に変換されます。
ドロップダウン メニューに該当する値が表示されない場合は、入力できます。〔Enter〕を押すと、バリデータはエンコーディングが有効かつサポートされていることを検証します。入力値は、拡張エンコーディング セットから入力することも、エンコーディング用の IANA 名、エリアス、または標準名にすることもできます。エンコーディングの検証に失敗すると、警告メッセージ「you can choose to override the validation and accept the value anyway」が表示されます。値は、デスクトップ encoding 属性に対して .portal ファイルにそのまま保存されます。
下位互換性のため、および接続解除された少数のデスクトップを使用可能にするために、WebLogic Portal バージョン 9.2 は新しいブール プロパティを備えています(非推奨)。これは、StandalonePortletURL および関連付けられた JSP タグ用の desktopStateShared と呼ばれています。このプロパティを使用すると、以前の「接続解除されたデスクトップ」の動作を残すことができます。このプロパティと属性のデフォルト値は true になり、その場合はポートレットがデスクトップに接続します。
URL またはタグの path プロパティまたは contextualPath プロパティを明示的に設定すると、接続元デスクトップからスタンドアロン ポートレットへの関連付けも解除されます。また、スタンドアロン ポートレットのコンテキスト内で生成されたすべての URL に対して true が保持されます。path または contextualPath の設定によって、URL と接続元デスクトップとの接続が解除されます。
以前のリリースの WebLogic Portal では、(非推奨でしたが) 同じ名前、階層の同じレベルで複数のポートレット カテゴリ名を作成することができました。バージョン 9.2 では、この操作は許可されません (複数のカテゴリに対して同じ名前を使用できますが、階層内で「ピア」にすることはできません)。
ポータル アプリケーションをバージョン 9.2 にアップグレードすると、以前使用していた重複するポートレット カテゴリ名は保持されます。カテゴリ名を編集してユニークにしてください。ユニークにしないと、WebLogic Portal 伝播ツールで予期しない結果が発生したり、伝播プロセス中にエラーが発生する恐れがあります。
WebLogic Portal 9.2 では、propagation.war の Propagation Utility Web アプリケーションが推奨されません。このアプリケーションは WebLogic Portal 8.1 SP4 用のパッチで導入された後、WebLogic Portal 8.1 SP5 に組み込まれました。WebLogic Portal エンタープライズ アプリケーションのルート ディレクトリにファイル propagation.war をインストール済みで、WebLogic Portal の Web アプリケーションをアップグレードする場合は、WebLogic Portal 9.2 へのアップグレード前または後にそのファイルを削除することをお勧めします。
  
|
