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アプリケーションのアップグレードに関連する項目について説明します。この付録には、次の項目が含まれます。
WebFlowおよびパイプラインはWebLogic Portal 9.2から非推奨となっており、現在はサポートされていません。これらの非推奨機能のかわりにページ・フローを使用してください。
次の各項では、ポータル・アプリケーションのアップグレード時に役立つ考慮事項およびヒントを紹介し、ポータル・アプリケーションのアップグレード後に手動での作業が必要になる可能性があるいくつかの状況について説明します。
このセクションの内容は次のとおりです。
Oracle Enterprise Pack for Eclipseでは、コマンド駆動型のアップグレード(upgradeStarter)およびantタスク・ベースのアップグレードを実行できます。WebLogic Portalではこれらの代替アップグレード方法はサポートされておらず、インポート・ウィザードを使用する必要があります。
インポート・ウィザードのプロセスの一環として、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>
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のフォーマットにアップグレードする手順は次のとおりです。
この付録およびOracle Enterprise Pack for Eclipseのドキュメントに記載されているように、ルック・アンド・フィールを含むポータル・アプリケーションがWebLogic Portal 10.3.4に変換されていることを確認します。
ルック・アンド・フィール・ファイル(.laf
ファイル)を開きます。
WebLogic Portalにより、関連する.properties
ファイルが自動的にアップグレードされます。アップグレード中に行われている変更についての情報メッセージが表示されます。図C-1に例を示します。
「OK」をクリックしてアップグレードを完了します。
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の変更の処理に関する項を参照してください。
フォーク表示またはフォーク事前表示を使用する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
)を参照してください。
インポート・ウィザードには、アップグレードされたアプリケーション用の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を使用してみることもできます。
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/tlds
のstruts-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-*
を参照するように編集します。
.tld
をstruts.jar
(struts-1.1.war
内)およびstruts-adapter.jar
の両方から抽出し、WEB-INF/tlds
にコピーします。これにより、web.xml
を使用した明示的なtldマッピングを引き続き使用できます。
WebLogic Portalの以前のリリースでは、WebLogic Portalによって生成されるURLの形式を構成するために、構成ファイルurl-template-config.xml
を使用していました。現在は、Beehiveの構成ファイルbeehive-url-template-config.xml
を使用します。以前の構成ファイルには、次のように、パラメータ区切り文字のかわりにアンパサンド・エンティティを含むURLを生成する要素(generate-xml-amp-entity
)が含まれていました。
http://www...?arg1=foo&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
ファイルに追加する必要があります。
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
ファイルの個々のインスタンスに対して、パッケージ・エクスプローラ内でファイル名を右クリックして「アップグレード」コンテキスト・メニューにアクセスすることにより、ファイルを変換できます。
WebLogic Portalの以前のリリースでは、推奨されてはいませんが、階層内の同じレベルに同じ名前のポートレット・カテゴリを複数作成することが可能でした。WebLogic 10.3.4では、この操作は許可されていません(複数のカテゴリに同じ名前を使用できますが、階層内で同じレベルに配置することはできません)。
ポータル・アプリケーションを10.3.4にアップグレードすると、以前使用されていた重複するポートレット・カテゴリ名は維持されます。これらのカテゴリ名が一意になるように編集することが非常に重要です。一意にしないと、WebLogic Portal伝播ツールで予期しない結果が発生したり、伝播プロセス中にエラーが発生する可能性があります。