|
|
WebLogic Portal 10.0 から WebLogic Portal 8.1 SP4+ アプリケーションをアップグレードする前に、Workshop for WebLogic アップグレードの手順とそれに関連する制限事項を知っておく必要があります。Workshop for WebLogic でのポータル アプリケーションのアップグレードの詳細については、「BEA edocs サイト上の Workshop for WebLogic アップグレード ページ」を参照してください。
Workshop for WebLogic のアップグレード ドキュメントは、アプリケーションが WebLogic Workshop 8.1 SP4+ を使用して開発されていることを前提としています。アプリケーションが WebLogic Workshop 8.1 SP4+ を使用して開発されたものでない場合には、ここに記載されているツールを使用して Workshop for WebLogic バージョン 10.0 にアップグレードする前に、コードのリファクタリングを実施して、アプリケーションを WebLogic Workshop IDE 8.1 SP4+ で構築および稼働させる必要があります。
この章では、WebLogic Portal アプリケーションのアップグレードに関する内容について説明します。この章には、以下の節が含まれます。
Webflow とパイプラインは WebLogic Portal 9.2 で非推奨になっていましたが、バージョン 10.0 ではサポート対象外になっています。これらの非推奨機能の代わりにページ フローを使用します。
以下の節では、ポータル アプリケーションをグレードアップする際に役に立つ可能性のある考慮事項とヒントについて説明します、また、ポータル アプリケーションをアップグレードした後で手動タスクが必要になる場合についても説明します。
Workshop for WebLogic では、コマンド駆動型のアップグレード (upgradeStarter) と Ant タスクベースのアップグレードが利用できます。WebLogic Portal はこれらのアップグレード方法をサポートしていないため、必ずインポート ウィザードを使用する必要があります。
WebLogic Portal 8.1.4+ からの変更されていない訪問者ツールのコードは、インポート ウィザード処理の一環としてアップグレードされます。ただし、WebLogic Portal 10.0 のコミュニティベースのコンポーネントはデフォルトで無効になります。これは、8.1.4+ を使用して開発されたプロジェクトがコミュニティに対応していないためです。
アップグレード プロセスの一環としてとして、インポート ウィザードは、コミュニティ関連の訪問者ツールを有効にするかどうかを規定する 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/100/communities-config">
<enable-community-tools>true</enable-community-tools>
WebLogic Portal 8.1.4+ では、ポータルのルック アンド フィールに対して、skin.properties (/skins/skin_name ディレクトリ) と skeleton.properties (/skeletons/skeleton_name ディレクトリ) という 2 つのコンフィグレーション ファイルを使用していました。どちらもテキスト ファイルで、skeleton.properties は任意でした。
WebLogic Portal 10.0 では、どちらのファイルも XML ファイルです。
WebLogic Portal 10.0 では、従来のコンフィグレーションも使用できますが、新しいルック アンド フィールを利用するには skin.xml と skeleton.xml を使用する必要があります。古い .properties ファイルのアップグレードは必須です。
WebLogic Portal 8.1 のルック アンド フィールを WebLogic Portal 10.0 形式にアップグレードするには、次の作業を行います。
.laf ファイル) を開きます。
WebLogic Portal によって、関連する .properties ファイルが自動的にアップグレードされます。アップグレード中に発生する変更は、情報メッセージによって通知されます。図 A-1 に例を示します。
WebLogic Portal 8.1 カスタム コントロールのアノテーション定義は、WebLogic Portal 10.0 にアップグレードされません。アノテーションを定義する方法は、Java 5 アノテーション モデルに基づいています。8.1 向けに記述されたコントロールをアップグレードするには、新しいモデルに合わせてアノテーション定義を書き換える必要があります。
カスタム アノテーションのアップグレードの詳細については、システム コントロール用の Apache Beehive ソース コードを確認してください。新しいモデルを使用するアノテーションが示されています。
WebLogic 8.1 からのコントロール コンテキスト API の変更については、Workshop for WebLogic オンライン ヘルプの「コンテキスト API の変更に対する処理」を参照してください。
フォーク表示またはフォーク事前表示を使用する 8.1 アプリケーション向けにスレッド プールを最適化している場合に、アプリケーションのアップグレード後もこれらの最適化を維持するには、アップグレード後にいくつかの手動タスクを実行する必要があります。
WebLogic Portal 10.0 では、WebLogic Portal は WebLogic Server の CommonJ ワークマネージャ インフラストラクチャを使用して、フォークされたポートレットの事前表示および表示を行います。ワークマネージャのコンフィグレーション パラメータ、動作、およびデプロイメント オプションは似ていますが、同じではありません。8.1.4 以降のアプリケーションをアップグレードする場合、portalRenderQueue スレッド プールに対する既存のカスタマイズは、フォークに使用されるデフォルトのワークマネージャに自動的に適用される訳ではありません。このワークマネージャをチューニングするには、ワークマネージャをコンフィグレーションして、wm/portalRenderQueueWorkManager という名前を割り当てます。WebLogic Server 10.0 におけるワークマネージャおよびスレッドの使用の詳細については、WebLogic Server ドキュメントの「ワーク マネージャを使用したスケジューリング済み作業の最適化」を参照してください。
インポート ウィザードでは、アップグレードされたアプリケーションに 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.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/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 の両方から .tld を抽出し、WEB-INF/tlds にコピーする。これにより、web.xml を使用した明示的 tld マッピングを引き続き使用できます。
以前のリリースで、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&arg2=bar (エンティティ)
http://www...?arg1=foo&arg2=bar (文字)
このコンフィグレーション ファイルが存在しない場合、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.0 で、MBean は記述子 Bean に変更されています。これまで application-config.xml に含まれていた設定は、以下のような関連する記述子 Bean コンフィグレーション ファイルに含まれています。
バージョン 8.1.4+ のアプリケーションを Workshop for WebLogic にインポートする場合、インポート プロセスによって必要な変換が行われます。8.1 の application-config.xml ファイルの各インスタンスを使用する場合には、パッケージ エクスプローラでファイル名を右クリックすると、ファイルを変換する アップグレード コンテキスト メニューにアクセスできます。
以前のリリースの WebLogic Portal では、(非推奨でしたが) 同じ名前、階層の同じレベルで複数のポートレット カテゴリ名を作成することができました。WebLogic 10.0 では、この操作は許可されません。(複数のカテゴリに対して同じ名前を使用できますが、階層内で「ピア」にすることはできません)。
ポータル アプリケーションを 10.0 にアップグレードすると、以前使用していた重複するポートレット カテゴリ名は保持されます。カテゴリ名を編集してユニークにしてください。ユニークにしないと、WebLogic Portal 伝播ツールで予期しない結果が発生したり、伝播プロセス中にエラーが発生する恐れがあります。
  
|
