ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Portalアップグレード・ガイド
10gリリース3(10.3.4)
B66149-01
  目次へ移動
目次

前
 
 

C WebLogic Portal 8.1プロジェクトのWebLogic Portal 10.3.4へのアップグレード

WebLogic Portal 8.1 SP4+のアプリケーションをWebLogic Portal 10.3.4にアップグレードする前に、Oracle Enterprise Pack for Eclipseのアップグレード手順および関連する制限事項について理解する必要があります。Oracle Enterprise Pack for Eclipseでのポータル・アプリケーションのアップグレードの詳細は、Workshop for WebLogicのアップグレードを参照してください。

Oracle Enterprise Pack for Eclipseのアップグレード・ドキュメントでは、アプリケーションがWorkshop for WebLogic 8.1 SP4+を使用して開発されていることを前提としています。違う場合は、ここで説明するツールを使用してWorkshop for WebLogic 10.3.4にアップグレードする前に、WebLogic Workshop for WebLogic IDE 8.1 SP4+でビルドおよび実行されるようにコードをリファクタする必要があります。

この付録では、特にWebLogic Portalアプリケーションのアップグレードに関連する項目について説明します。この付録には、次の項目が含まれます。

C.1 WebLogic Portal 10.3.4でサポートされていないWebLogic Portal 8.1の機能

WebFlowおよびパイプラインはWebLogic Portal 9.2から非推奨となっており、現在はサポートされていません。これらの非推奨機能のかわりにページ・フローを使用してください。

C.2 アップグレード時の考慮事項およびヒント

次の各項では、ポータル・アプリケーションのアップグレード時に役立つ考慮事項およびヒントを紹介し、ポータル・アプリケーションのアップグレード後に手動での作業が必要になる可能性があるいくつかの状況について説明します。

このセクションの内容は次のとおりです。

C.2.1 コマンド・ベースおよびAntタスクでのアップグレードはサポートされていない

Oracle Enterprise Pack for Eclipseでは、コマンド駆動型のアップグレード(upgradeStarter)およびantタスク・ベースのアップグレードを実行できます。WebLogic Portalではこれらの代替アップグレード方法はサポートされておらず、インポート・ウィザードを使用する必要があります。

C.2.2 アップグレードされたビジター・ツールでのコミュニティ機能の有効化

インポート・ウィザードのプロセスの一環として、WebLogic Portal 8.1.4+からの未変更のビジター・ツールのコードがアップグレードされます。ただし、WebLogic Portal 10.3.4のコミュニティ・ベースのコンポーネントはデフォルトで無効化されます。これは、8.1.4+を使用して開発されたプロジェクトがコミュニティに対応していないためです。

アップロード・プロセスの一環として、インポート・ウィザードにより、コミュニティ関連のビジター・ツールを有効化するかどうかを定義するcommunities-config.xmlファイルがEARプロジェクトの/META-INFディレクトリに作成されます。この機能を有効にするには、次の例に示すように、enable-community-tools属性のフラグをtrueに設定します。

<?xml version="1.0" encoding="UTF-8"?>
<communities-config xmlns="http://www.bea.com/ns/portal/100/communities-config">
   <enable-community-tools>true</enable-community-tools>
</communities-config>

C.2.3 ルック・アンド・フィールのアップグレード

WebLogic Portal 8.1.4+のポータルのルック・アンド・フィールでは、スキンとスケルトンに、skin.properties(/skins/skin_nameディレクトリ)とskeleton.properties(/skeletons/skeleton_nameディレクトリ)という2つの構成ファイルを使用していました。どちらもテキスト・ファイルであり、skeleton.propertiesはオプションでした。

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

WebLogic Portal 10.3.4では、レガシー構成を使用することも可能ですが、新しいルック・アンド・フィール機能を利用するにはskin.xmlおよびskeleton.xmlを使用する必要があります。古い.propertiesファイルのアップグレードが必要です。

WebLogic Portal 8.1のルック・アンド・フィールをWebLogic Portal 10.3.4のフォーマットにアップグレードする手順は次のとおりです。

  1. この付録およびOracle Enterprise Pack for Eclipseのドキュメントに記載されているように、ルック・アンド・フィールを含むポータル・アプリケーションがWebLogic Portal 10.3.4に変換されていることを確認します。

  2. ルック・アンド・フィール・ファイル(.lafファイル)を開きます。

    WebLogic Portalにより、関連する.propertiesファイルが自動的にアップグレードされます。アップグレード中に行われている変更についての情報メッセージが表示されます。図C-1に例を示します。

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

    図C-1の説明が続きます。
    「図C-1 ルック・アンド・フィール・ファイルを開いたときのプロパティ・ファイルの変換」の説明

  3. 「OK」をクリックしてアップグレードを完了します。

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

WebLogic Portal 8.1のカスタム・コントロールの注釈定義はWebLogic Portal 10.3.4にアップグレードされません。注釈を定義する方法は、Java 5の注釈モデルに基づいています。8.1用に記述されたコントロールをアップグレードするには、新しいモデルに合わせて注釈定義を書き換える必要があります。

カスタム注釈のアップグレードの詳細は、Apache Beehiveソース・コードのシステム・コントロールを参照してください。新しいモデルを使用する注釈が記述されています。

コントロール・コンテキストAPIがWebLogic 8.1からどのように変更されているかについては、Oracle Enterprise Pack for Eclipseオンライン・ヘルプのコンテキストAPIの変更の処理に関する項を参照してください。

C.2.5 フォークされるポートレット用にチューニングされたスレッド・プールのアップグレード

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

WebLogic Portal 10.3.4では、WebLogic ServerのCommonJ WorkManagerインフラストラクチャを使用して、フォークされるポートレットの事前表示および表示を行います。各WorkManagerの構成パラメータ、動作およびデプロイメント・オプションは似ていますが、同一ではありません。8.1.4+アプリケーションをアップグレードすると、portalRenderQueueスレッド・プールに対する既存のカスタマイズは、フォークに使用されるデフォルトのWorkManagerに自動的に適用されません。このWorkManagerをチューニングするには、WorkManagerを構成し、wm/portalRenderQueueWorkManagerという名前を関連付けます。WorkManagerおよびWebLogic Server 10.0でのスレッドの使用の詳細は、WorkManagerを使用したスケジュール済作業の最適化に関する項(http://download-llnw.oracle.com/docs/cd//E13222_01/wls/docs100/config_wls/self_tuned.html)を参照してください。

C.2.6 アップグレードされたアプリケーションはStruts 1.1および関連J2EEライブラリを使用する

インポート・ウィザードには、アップグレードされたアプリケーション用のStruts 1.1共有J2EEライブラリが含まれます。Struts 1.1 J2EEライブラリは、アップグレードされたアプリケーションの操作性を維持するために使用されます。アップグレードされたアプリケーションでStruts 1.2を使用できるようにするには、Struts 1.1に明示的に依存するページ・フローまたはポートレットのコードをすべて手動で更新する必要があります(詳細は、第C.2.7項「Struts 1.1と1.2での動作の違い」を参照)。

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

C.2.7 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ライブラリを使用する必要があります。

Struts 1.2にアップグレードするアプリケーションの場合、web.xmlを使用してstrutsとstruts-adapter taglibをマップするかわりに、WebLogic Portalでは現在JSP 1.2の暗黙的なtaglibマッピングを使用しているため、JARのMETA-INFディレクトリの.tldファイルは、Webコンテナによって、tldに指定されているURIに暗黙的にマップされます。WebLogic Portalでは、これらはパスMETA-INF/tldsstruts-adapter.jarにあります。

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

  • struts taglibを使用するすべてのJSPを、HTMLおよびネストされたtaglibについてはhttp://bea.com/struts/adapter/tags-htmlおよびhttp://bea.com/struts/adapter/tags-nestedを参照するように、ポータル・アダプタによってオーバーライドされない残りのtaglibについてはhttp://struts.apache.org/tags-*を参照するように編集します。

  • .tldstruts.jar(struts-1.1.war内)およびstruts-adapter.jarの両方から抽出し、WEB-INF/tldsにコピーします。これにより、web.xmlを使用した明示的なtldマッピングを引き続き使用できます。

C.2.8 ポータルURL内のアンパサンド・エンティティ

WebLogic Portalの以前のリリースでは、WebLogic Portalによって生成されるURLの形式を構成するために、構成ファイルurl-template-config.xmlを使用していました。現在は、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ファイルに追加する必要があります。

C.2.9 後からの個々のapplication-config.xmlファイルのアップグレード

WebLogic Portalバージョン8.1.4+を使用して作成されたアプリケーションでは、各種のMBeanの構成にMETA-INF/application-config.xmlファイルが使用されていました。WebLogic Portal 10.3.4では、MBeanは記述子Beanに変更されています。application-config.xmlに以前含まれていた設定は、現在は次のような記述子Bean構成ファイルに含まれています。

  • content-config.xml

  • p13n-config.xml

  • p13n-cache-config.xml

  • p13n-security-config.xml

  • wps-config.xml

バージョン8.1.4+アプリケーションをOracle Enterprise Pack for Eclipseにインポートすると、インポート・プロセスによって必要な変換が実行されます。使用する8.1のapplication-config.xmlファイルの個々のインスタンスに対して、パッケージ・エクスプローラ内でファイル名を右クリックして「アップグレード」コンテキスト・メニューにアクセスすることにより、ファイルを変換できます。

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

WebLogic Portalの以前のリリースでは、推奨されてはいませんが、階層内の同じレベルに同じ名前のポートレット・カテゴリを複数作成することが可能でした。WebLogic 10.3.4では、この操作は許可されていません(複数のカテゴリに同じ名前を使用できますが、階層内で同じレベルに配置することはできません)。

ポータル・アプリケーションを10.3.4にアップグレードすると、以前使用されていた重複するポートレット・カテゴリ名は維持されます。これらのカテゴリ名が一意になるように編集することが非常に重要です。一意にしないと、WebLogic Portal伝播ツールで予期しない結果が発生したり、伝播プロセス中にエラーが発生する可能性があります。