ポータル開発ガイド

     前  次    新しいウィンドウで目次を開く     
ここから内容

WebLogic Portal プロジェクトのバージョン 9.2 へのアップグレード

BEA Workshop for WebLogic Platform プログラマーズ ガイド』は、Workshop for WebLogic のヘルプの一部として使用でき、ポータル アプリケーションのアップグレードを準備する場合に便利なトピックがいくつか記載されています。Workshop for WebLogic のドキュメントにはインポート ウィザードを使用する場合の手順、アップグレード プロセス中に起こることの詳細、およびアップグレード タスクの前後に必要な手動のタスクが記載されています。

WebLogic Portal アプリケーションをバージョン 8.1 4 または 8.1.5 からバージョン 9.2 にアップグレードする前に、Workshop for WebLogic のアップグレード手順とそれに関連する制限事項を知っておくことが重要です。続行する前に、e-docs の『Workshop for WebLogic』ドキュメントを参照するか、製品のメイン メニューで [ヘルプ|ヘルプ目次] をクリックして、『BEA Workshop for WebLogic Platform プログラマーズ ガイド』を参照してください。

Workshop for WebLogic のアップグレード ドキュメントは、アプリケーションが WebLogic Workshop バージョン 8.1 を使用して開発されていることを前提としています。アプリケーションが WebLogic Workshop バージョン 8.1 を使用して開発されたものでない場合には、ここに記載されているツールを使用して Workshop for WebLogic バージョン 9.2 にアップグレードする前に、コードのリファクタリングを実施して、アプリケーションを WebLogic Workshop IDE バージョン 8.1 SP4 または SP5 で構築および稼働させる必要があります。

この章では、WebLogic Portal アプリケーションのアップグレードに関する内容について説明します。この章には、以下の節が含まれます。

 


バージョン 9.2 でサポートされていないバージョン 8.1 の機能

Webflow とパイプラインはバージョン 8.1 で非推奨になっていましたが、バージョン 9.2 ではサポート対象外になっています。これらの非推奨機能の代わりにページ フローを使用します。

 


アップグレード時の考慮事項とヒント

以下の節では、ポータル アプリケーションをグレードアップする際に役に立つ可能性のある考慮事項とヒントについて説明します、また、ポータル アプリケーションをアップグレードした後で手動タスクが必要になる場合についても説明します。

この節では、次のトピックについて説明します。

サポート対象外のコマンドベースおよび Ant タスク アップグレード

Workshop for WebLogic では、コマンド駆動型のアップグレード (upgradeStarter) と Ant タスクベースのアップグレードが利用できます。WebLogic Portal はこれらのアップグレード方法をサポートしていないため、必ずインポート ウィザードを使用する必要があります。

アップグレードされた訪問者ツールでのコミュニティ機能の有効化

WebLogic Portal 8.1.4 以降からの変更されていない訪問者ツールのコードは、インポート ウィザード処理の一環としてアップグレードされます。ただし、新しいバージョン 9.2 のコミュニティベースのコンポーネントはデフォルトで無効になります。これは、バージョン 8.1.x を使用して開発されたプロジェクトがコミュニティに対応していないためです。

アップグレード プロセスの一環としてとして、インポート ウィザードは、コミュニティ関連の訪問者ツールを有効にするかどうかを規定する EAR プロジェクトの /META-INF ディレクトリに communities-config.xml ファイルを作成します。この機能を有効にするには、enable-community-tools 属性のフラグを true に設定します (以下の例を参照)。

<?xml version="1.0" encoding="UTF-8"?>

<communities-config xmlns="http://www.bea.com/ns/portal/90/communities-config">

   <enable-community-tools>true</enable-community-tools>

</communities-config>

ルック アンド フィールのアップグレード

WebLogic Portal 8.1 では、ポータルのルック アンド フィールに対して、skin.properties (/skins/skin_name ディレクトリ) と skeleton.properties (/skeletons/skeleton_name ディレクトリ) という 2 つのコンフィグレーション ファイルを使用していました。どちらもテキスト ファイルで、skeleton.properties は任意でした。

WebLogic Portal 9.2 では、どちらのファイルも XML ファイルです。

バージョン 9.2 では、従来のコンフィグレーションも使用できますが、新しいルック アンド フィールを利用するには skin.xmlskeleton.xml を使用する必要があります。古い .properties ファイルのアップグレードは必須です。

WebLogic Portal 8.1 のルック アンド フィールを WebLogic Portal 9.2 形式にアップグレードするには、次の作業を行います。

  1. この章と Workshop for WebLogic ドキュメントの説明に従って、ルック アンド フィールを含むポータル アプリケーションが WebLogic Portal 9.2 に変換されていることを確認します。
  2. ルック アンド フィール ファイル (.laf ファイル) を開きます。
  3. 関連する .properties ファイルは WebLogic Portal によって自動的にアップグレードされます。アップグレード中に発生する変更は、情報メッセージによって通知されます。図 5-1 に例を示します。

    図 5-1 ルック アンド フィール ファイルを開いたときのプロパティ ファイルの変換


    ルック アンド フィール ファイルを開いたときのプロパティ ファイルの変換

  4. [OK] をクリックしてアップグレードを完了します。

カスタム プロパティを持つカスタム コントロールのアップグレード

バージョン 8.1 カスタム コントロールのアノテーション定義は、Version 9.2 にアップグレードされません。アノテーションを定義する方法は、Java 5 アノテーション モデルに基づいています。バージョン 8.1 向けに記述されたコントロールをアップグレードするには、新しいモデルに合わせてアノテーション定義を書き換える必要があります。

カスタム アノテーションのアップグレードの詳細については、システム コントロール用の Apache Beehive ソース コードを確認してください。新しいモデルを使用するアノテーションが示されています。

バージョン 8.1 からのコントロール コンテキスト API の変更については、Workshop for WebLogic オンライン ヘルプの「コンテキスト API の変更に対する処理」を参照してください。

フォークされたポートレット向けにチューニングされたスレッド プールのアップグレード

フォーク表示またはフォーク事前表示を使用する 8.1 アプリケーション向けにスレッド プールを最適化している場合に、アプリケーションのアップグレード後もこれらの最適化を維持するには、アップグレード後にいくつかの手動タスクを実行する必要があります。

バージョン 9.2 では、WebLogic Portal は WebLogic Server の CommonJ ワークマネージャ インフラストラクチャを使用して、フォークされたポートレットの事前表示および表示を行います。ワーク マネージャのコンフィグレーション パラメータ、動作、およびデプロイメント オプションは似ていますが、同じではありません。8.1.4 以降のアプリケーションをアップグレードする場合、portalRenderQueue スレッド プールに対する既存のカスタマイズは、フォークに使用されるデフォルトのワーク マネージャに自動的に適用される訳ではありません。このワークマネージャをチューニングするには、ワークマネージャをコンフィグレーションして、wm/portalRenderQueueWorkManager という名前を割り当てます。WebLogic Server 9.2 におけるワークマネージャおよびスレッドの使用の詳細については、WebLogic Server ドキュメントの「ワーク マネージャを使用したスケジューリング済み作業の最適化」を参照してください。

アップグレードされたアプリケーションによる Struts 1.1 および関連 J2EE ライブラリの利用

インポート ウィザードでは、アップグレードされたアプリケーションに Struts 1.1 共有 J2EE ライブラリが組み込まれます。Struts 1.1 共有 J2EE ライブラリは、アップグレードされたアプリケーションの動作を維持するために使用されます。アップグレードされたアプリケーションで Struts 1.2 が使用できるまでの間、Struts 1.1 に明示的に依存しているページ フローやポートレットのコードは手動でアップグレードする必要があります (詳細については、「Struts 1.1 と 1.2 間における動作の変更」を参照)。

新しいポータル Web プロジェクトには Struts 1.2 共有 J2EE ライブラリがデフォルトで組み込まれますが、必要に応じて Struts 1.1 を選択できます。新しいアプリケーションでは、デフォルト設定のまま Struts 1.2 を使用することを強く推奨します。アップグレードされたアプリケーションの場合でも、Struts 1.2 の利用は有効です (可能な場合)。Struts 1.1 への明示的な依存が実際に存在するかどうかを確認するために、Struts1.2 を試しに使用することもできます。

Struts 1.1 と 1.2 間における動作の変更

Struts 1.2 にアップグレードする場合、Struts に対する WebLogic Portal のサポートは若干異なります。

WebLogic Portal の Struts 1.1 サポートは以前のリリースと同じであり、web.xml を使用して struts-adapter taglib が URI にマップされます。この場合には、新しい struts-1.2.war J2EE ライブラリの代わりに、struts-1.1.war J2EE ライブラリを使用する必要があります。

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/tldsstruts-adapter.jar にあります。

Struts 1.2 にアップグレードするには、次の 2 種類の方法のいずれかを選択します。

ポータル URL 内のアンパサンド

以前のリリースで、WebLogic Portal はコンフィグレーション ファイル url-template-config.xml を使用して、WebLogic Portal によって生成される URL のフォームをコンフィグレーションしていました。最新のリリースで、WebLogic Portal は Beehive の beehive-url-template-config.xml を使用します。従来のコンフィグレーション ファイルには、次のように、パラメータの区切り文字としてアンパサンド文字ではなくアンパサンド エンティティを使用して URL を生成する要素 (generate-xml-amp-entity) が含まれていました。

http://www...?arg1=foo&amp;arg2=bar (entity)

ではなく、

http://www...?arg1=foo&arg2=bar (character)

このコンフィグレーション ファイルが存在しない場合、URL はアンパサンド文字を使って生成されました。

アンパサンド エンティティに対応した Beehive コンフィグレーション要素は、NetUI コンフィグレーション ファイル (beehive-netui-config.xml) 内にあります。アンパサンド エンティティの Beehive デフォルトは、従来のポータル デフォルトの逆になっています。コンフィグレーション要素が存在しない場合、URL はアンパサンド エンティティを使用して生成されます。

ポータル フレームワークでは、NetUI コンフィグレーション ファイルがこのコンフィグレーション要素のソースとして使用されます。また、Beehive セマンティクスも使用されます。これは、ポータルで生成される URL には、デフォルトで、アンパサンド エンティティが含まれることを意味しています。これは HTML コンフィグレーションのみに適用されます。XHTML コンフィグレーションではコンフィグレーション設定に関係なく URL でアンパサンド エンティティが使用されます。

アンパサンド エンティティではなく文字を使用して URL を生成する必要がある場合には、beehive-netui-config.xml ファイルにそのコンフィグレーション要素を追加する必要があります。

application-config.xml ファイルの個別アップグレード

WebLogic Portal バージョン 8.1.x を使用して作成されたアプリケーションでは、各種 MBean のコンフィグレーションに META-INF/application-config.xml ファイルが使用されていました。バージョン 9.2 で、MBean は記述子 Bean に変更されています。これまで application-config.xml に含まれていた設定は、以下のような関連する記述子 Bean コンフィグレーション ファイルに含まれています。

バージョン 8.1.4 以降のアプリケーションを Workshop for WebLogic にインポートする場合、インポート プロセスによって必要な変換が行われます。バージョン 8.1 の application-config.xml ファイルの各インスタンスを使用する場合には、パッケージ エクスプローラでファイル名を右クリックすると、ファイルを変換するアップグレード コンテキスト メニューにアクセスできます。

アップグレードされたアプリケーションを伝播する前の重複ポートレット カテゴリ名の修正

以前のリリースの WebLogic Portal では、(非推奨でしたが) 同じ名前、階層の同じレベルで複数のポートレット カテゴリ名を作成することができました。バージョン 9.2 では、この操作は許可されません (複数のカテゴリに対して同じ名前を使用できますが、階層内で「ピア」にすることはできません)。

ポータル アプリケーションをバージョン 9.2 にアップグレードすると、以前使用していた重複するポートレット カテゴリ名は保持されます。カテゴリ名を編集してユニークにしてください。ユニークにしないと、WebLogic Portal 伝播ツールで予期しない結果が発生したり、伝播プロセス中にエラーが発生する恐れがあります。


  ページの先頭       前  次