| ドキュメントのダウンロード | サイト マップ | 用語集 | |
|
|||
| BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Platform > WebLogic Portal > リリース ノート > リリース 7.0 Service Pack 7 |
|
リリース ノート
|
リリース 7.0 Service Pack 7
リリース 7.0 をインストールして使用する前に、以下の情報を確認してください。
新機能
WebLogic Portal アプリケーションの実行用にコンフィグレーションされたドメインをコンフィグレーションして、WebLogic Server 7.0 で導入された WebLogic セキュリティ サービスを使用できるようになりました。複数の認証プロバイダを使用できますが、特定の管理作業は単一プロバイダに制限されます。詳細については、「Switching to a WebLogic 7.0 Security Framework Security Realm」を参照してください。
移行についての情報
WebLogic Platform 7.0 のサービス パックには、Platform 7.0 のすべてのコンポーネント (WebLogic Server、WebLogic Workshop、WebLogic Integration、WebLogic Portal、および WebLogic JRockit) の更新用サービス パックが組み込まれています。
旧バージョンの製品を使用して開発したアプリケーションがある場合、以前のデータおよびカスタマイズをリリース 7.0 およびそのサービス パックのインストール環境で利用可能にするには、『移行ガイド』 (http://edocs.beasys.co.jp/e-docs/platform/docs70/interm/migrate.html) を参照してください。
インストール
WebLogic Portal 7.0、およびそのサービス パックのインストール方法については、『WebLogic Platform のインストール』(http://edocs.beasys.co.jp/e-docs/platform/docs70/install/index.html) を参照してください。
データベースのコンフィグレーションに関して必要な変更
データベースのコンフィグレーションに関する考慮事項については、『管理者ガイド』(http://edocs.beasys.co.jp/e-docs/wlp/docs70/admin/index.htm) の「システム管理」を参照してください。
統合されている製品の使用に関する注意
サード パーティ製のソフトウェア、サービス、およびアプリケーションに接続し、その動作環境下で WebLogic Portal を使用する場合は、すべてユーザ自身の責任において行うものとします。BEA Systems 社は、このようなソフトウェア、サービス、およびアプリケーションの動作、精度、および結果に対して、いかなる義務および責任も負いません。
サポート対象のプラットフォームについての参照情報
サポート対象のハードウェアとソフトウェアのプラットフォーム、およびそれに関連する動作確認については、「サポート対象のコンフィグレーション」(http://edocs.beasys.co.jp/e-docs/platform/suppconfigs/index.html) を参照してください。新しいプラットフォームの動作確認が完了すると、この情報は更新されます。最新の情報を確実に表示するには、ブラウザのキャッシュを更新する必要があります。ファイルの最終更新日は、ブラウザ ウィンドウのタイトル バーに表示されます。
解決された制限事項
この節では、WebLogic Portal 7.0、7.0 Service Pack 1 から Service Pack 7 で解決された確認済み制限事項について説明します。詳細については、以下の節を参照してください。
7.0 Service Pack 7 で解決された制限事項
7.0 Service Pack 7 で解決された制限事項はありません。
7.0 Service Pack 5 および 6 で解決された制限事項
この節では、WebLogic Portal の旧バージョンで確認されていた制限事項のうち、7.0 Service Pack 5 および 6 で解決されたものについて説明します。
7.0 Service Pack 4 で解決された制限事項 この節では、WebLogic Portal の旧バージョンで確認されていた制限事項のうち、7.0 Service Pack 4 で解決されたものについて説明します。
7.0 Service Pack 2 で解決された制限事項 この節では、WebLogic Portal の旧バージョンで確認されていた制限事項のうち、7.0 Service Pack 2 で解決されたものについて説明します。
7.0 Service Pack 1 で解決された制限事項 この節では、WebLogic Portal の旧バージョンで確認されていた制限事項のうち、7.0 Service Pack 1 で解決されたものについて説明します。
7.0 で解決された制限事項 この節では、WebLogic Portal の旧バージョンで確認されていた制限事項のうち、7.0 で解決されたものについて説明します。
7.0 において確認されている制限事項とその回避策
以下の節では、WebLogic Portal 7.0 の問題に関する確認済みの制限事項と回避策を、製品を構成する要素別に説明します。
詳細については、以下の節を参照してください。
E-Business Control Center に関する問題
この節では、E-Business Control Center に関する問題による確認済みの制限事項とその回避策について説明します。以下の表に加えて、詳細については次の節を参照してください。
ポータルとポートレットに関する問題
この節では、E-Business Control Center におけるポータルとポートレットの問題に関する確認済みの制限事項とその回避策について説明します。
ポータル開発および管理に関する問題 この節では、一般的なポータル管理の問題に関する確認済みの制限事項と回避策について説明します。
CR109615 に関する補足情報 SP4 のリリースで、ポートレットの Webflow がネームスペースを認識できるようになったことにより、既存の Webflow、特に SP4 より前の WebLogic Portal サンプルに基づく Webflow で再帰の問題が発生するおそれがあります。この問題は例によって十分に説明されていますが、さまざまな理由により Webflow に影響を与える場合があります。 新しいポータル Web アプリケーションの作成時に取得する標準のポータル Webflow には、たとえばワイルドカード表示更新イベント (bea.portal.framework.internal.refresh) が含まれています。このイベントは preProcessor (com.bea.portal.appflow.processor.PreProcessor) に転送され、そこから postProcessor コンポーネント (com.bea.portal.appflow.processor.PostProcessor) に渡されます。イベントのタイプに関係なく、postProcessor はポータル内の全ポートレットの更新を試みます。 7.0 SP2 の e2e サンプルの b2c アプリケーションでは、カタログ ポートレット Webflow、特に addProductItemToShoppingCart Pipeline コンポーネントの処理中にエラーが起きると問題が発生します。Pipeline コンポーネントが PipelineException を送出すると、catalogportlet Webflow は、ポータル ネームスペース内のエラー プレゼンテーション ノード (error.jsp) のプロキシであるプロキシ ノード portal_error に転送され、標準の Webflow エラー ページが表示されます。この Webflow の他のエラーもすべて同じ方法で転送されます。 ユーザがポータルの [Products] タブ (URL - http://localhost:7501/b2cPortal/application?origin=hnav_bar.jsp&;event=bea.portal.framework.internal.refresh&pageid=Products) を再度クリックしようとすると、ポータルの表示更新イベント (bea.portal.framework.internal.refresh) がトリガされ、最終的に postProcessor はすべてのポートレットの更新を試みることになります。 catalogportlet が更新されても (bea.portal.framework.internal.refresh)、その Webflow catalogportlet では前述のエラーの状態が保持されます。つまり、catalogportlet はポータル ネームスペースの error.jsp にあります。Webflow エグゼキュータは、ポータルのエラー ノードに固有の表示更新イベントを認識しないため、フォールバックを行ってワイルドカードを使用します。その結果、postProcessor に戻ることになり、スタックのオーバーフローが発生するまでポートレットの更新が繰り返されます。 catalogportlet Webflow への別のエントリ ポイントを見つけることにより、問題を回避できる場合もあります。たとえば、e2e アプリケーションで [My Avitek] ページの下部にはカタログに戻る商品リンクが設定されており、catalogportlet Webflow を使用可能な状態に戻すことができます。 この問題を解決する最良の方法は、各 Webflow でエラー ページを変更することです。ポータル ネームスペースにフローを転送してそのエラー ノードを使用するのではなく、それぞれのポートレット ネームスペースにエラー プレゼンテーション ノードを作成し、同一の error.jsp を使用します。これにより、ポートレット自身の更新パスを使用して各ポートレットを回復できます。一般に、ポートレット Webflow をポータル Webflow に転送することは必ずしも得策ではありません。これを実行する場合は、何らかの復帰の手段を内部的に講じる必要があります。SP4 に付属しているサンプルは、このように更新されています。 Webflow でネームスペースが変更されない lastContentUrl ノードのような一部の例外もあります。これは、このノードがポートレットの最後の状態に戻す機能を備えているからです。さらに、一連の Webflow を作成することも考えられます。その際、ポートレット Webflow をポータル フローに正常に転送し、最終的には元に戻しますが、これには十分な注意が必要です。また、特別なプロセッサを少なくとも 1 つ以上作成する必要があります。このプロセッサには、前述のようなルーティングを受け入れ、元のネームスペースへのフローの復帰を処理するための機能を用意しなければなりません。 e2e の b2c アプリケーションのログイン プロセスは、クロス Webflow ネームスペースがいかに有用なもので、ときには必須のものであるかを示しています。このプロセスは、security.wf で始まる 3 つの Webflow に関連しています。正常にログインすると、Webflow は user_account.wf に転送され、最終的にはポータルが表示されるポータル ネームスペースになります。この場合、ログイン プロセスは基本的にポータル ページへの一方向パスなので、このパスは意味を成します。さらに、[ログアウト] ボタンを押してこの Webflow に戻ることもできます。 スタックのオーバーフローを引き起こす Webflow とログイン Webflow を区別するもう 1 つの特徴は、ログイン Webflow は特定のポートレットに関連付けられていないことです。この特徴と、更新メカニズムを理解することが、再帰の問題を回避するための重要なポイントです。再起の問題は、ポートレットの Webflow が最終的にポータル ネームスペースになり、戻る方法がないときに発生することに留意してください。ポータルの表示更新イベントが発生するとポートレットは更新されますが、ポートレットの Webflow はポータル ネームスペースにあるため、Webflow は、ポートレットを更新する試みへと戻すポータルの更新パスをたどります。これが再帰ループです。 ブラウザに関する問題 この節では、ブラウザの問題に関する確認済みの制限事項と回避策について説明します。
システム管理に関する問題 この節では、一般的なシステム管理の問題に関する確認済みの制限事項と回避説明します。以下の表に加えて、詳細については後の節も参照してください。
CR086602 の回避策 この回避策は、アプリケーションだけでなくドメインのウィザード テンプレートでも行う必要があります。製品のインストール ディレクトリ全体を検索すれば、EJB JAR ファイルが見つかります。 ロール マッピングの変更に加えて、usermgmt.jar に含まれる UserManager EJB デプロイメント記述子 (META-INF/ejb-jar.xml) の ProtectedGroupNames のリストも更新する必要があります。 EJB に対するロール マッピングを変更するには、EJB JAR から META-INF/weblogic-ejb-jar.xml を抽出し、セキュリティ ロール マッピングのグループ名を編集して、新しい META-INF/weblogic-ejb-jar.xml で EJB JAR を更新する必要があります。作業ディレクトリが深くネストしている場合は、「jar uvf campaign.jar META-INF/weblogic-ejb-jar.xml」などのコマンドの使用に十分注意してください。作業ディレクトリへのパスが長すぎると、jar コマンドで処理できない場合があります。その場合は、ルート ディレクトリに近いディレクトリに JAR ファイルをコピーして更新し、更新後の JAR を J2EE アプリケーション ディレクトリに戻してください。 Web アプリケーションに対するロール マッピングを変更するには、WEB-INF/weblogic.xml. の security-role-assignments を更新する必要があります。 たとえば、次に示すのは、7.0 Service Pack 1 の sampleportal の J2EE アプリケーションに対する EJB JAR のうち、更新を必要とするロール マッピングを含むものの一覧です。
META-INF/ejb-jar.xml: usermgmt.jar の ProtectedGroupNames の env-entry を忘れずに変更してください。
たとえば、7.0 SP1 の sampleportal の J2EE アプリケーションに対する Web アプリケーションのうち、更新を必要とするロール マッピングを含むものには、datasync、tools、toolSupport などがあります。委託されたポータル管理者がすでに存在する既存のインストール環境では、これらのロール マッピングを変更しないでください。最初に、WebLogic Server システム管理者またはポータル システム管理者としてポータル JSP 管理ツールにログインし、すべてのポータル管理者とグループ管理者を削除します。
新しいグループ名マッピングを受け入れるようにサーバを再コンフィグレーションした後は、ポータル JSP 管理ツールを使用してすべてのポータル管理者とグループ管理者を作成できます。
インターナショナライゼーションに関する問題
この節では、インターナショナライゼーションの問題に関する確認済みの制限事項と回避策について説明します。
移行に関する問題 この節では、WebLogic Portal の旧バージョンから 7.0 への移行に関する確認済みの制限事項とその回避策について説明します。
その他の注意事項
この節では、現時点では回避策のない問題について説明します。たとえば、サードパーティの欠陥に関する問題や、WebLogic Portal 7.0 の機能の説明が必要な問題などです。
wlcs_customer タイプのユーザに対しては、CustomerProperties プロパティ セットのプロパティを null に設定できないので、このタイプのユーザはプロパティ セットのデフォルト値を継承できません。この問題は、顧客以外のプロファイル、および顧客プロファイルの他のプロパティには影響しません。
CustomerProperties の値を null に設定すると、WebLogic Portal Administration Tools では CustomerProperties プロパティ セットに対する継承されたデフォルト値が表示されますが、getProperty の呼び出しからは空の文字列が返されます。
TABLE COLUMN LOB TYPE/SIZE
P13N
SAMPLE_UUP_INFO USER_INFO CLOB(8K)
DATA_SYNC_ITEM XML_DEFINITION CLOB(500K)
AD_BUCKET AD_QUERY CLOB(25K)
MAIL_MESSAGE MESSAGE_TEXT CLOB(25K)
PLACEHOLDER_PREVIEW XML_DEFINITION CLOB(25K)
ENTITLEMENT_RULESET RULESET_DOCUMENT CLOB(256K)
CATALOG_PROPERTY_VALUE BLOB_VALUE BLOB(8K)
PROPERTY_VALUE BLOB_VALUE BLOB(10K)
WLCS
DISCOUNT DISCOUNT_RULE CLOB(8K)
EVENT/BEHAVIOR TRACKING
TABLE EVENT XML_DEFINITION CLOB(200K)
<Oct 15, 2001 5:40:12 PM MDT> <Error> <Usermgmt> <Password change failed for
user testuser1>
Runtime Error...
Remote exception UserManager
Stack Trace...
com.bea.p13n.appflow.exception.ProcessingException:Remote exception
UserManager at
com.bea.portal.appflow.processor.security.SetPasswordFormProcessor.setPassword(SetPasswordFormProcessor.java:145)
at. . .
この問題は、あるクラスのメソッドが、同じクラスまたはそのクラスがベースになっているクラスの別のメソッドを呼び出している場合に発生します。この呼び出しは、「variableName.getValue()」や「ClassName.getValue()」のようなタイプの呼び出しではなく、「getValue()」のような単純なメソッド呼び出しによって行われます。
コード移行ツールは、「this.getValue()」のような呼び出しを正しく解釈しますが、このとき、処理対象のファイルに存在するすべての implements 文と extends 文を見つけて、そのクラスの定義自体だけから派生しているものと見なします。この想定は、別のクラスを継承する内部クラスが同じファイル内で定義されているような場合には正しくありません。これらの文で任意の種類のマップ エントリを持つ最初のものは、そのメソッドに対して必要な注釈であると見なされます。分析対象のソース ファイルの違いにより、この問題の出現状況にはいくつかの種類があります。
たとえば、分析対象のクラスが、変更されたクラスを継承している場合や変更されたインタフェースを実装している場合、またはマップ ファイルで注釈が必要と指定されているだけの場合でも、この問題が発生する可能性があります。メソッドがサブクラスで定義されていて、マップで実際に指定されているクラスまたはインタフェースでは定義されていない場合でも、そのメソッドには常に注釈が付きます。
もう 1 つの例として、あるクラスの中で定義されている内部クラスが、移行マップのいずれかで参照されているクラスを継承または実装している場合にも、この問題が発生します。次に示すのは、この問題が発生する Test クラスの一部です。
public class Test {
public void testExtendsImplements() {
class MinorCowboys extends Cowboys {
}
class HighSchoolCowboys extends nfl.dallas.Cowboys {
}
class Raiders implements Cowboys {
}
class MinorRaiders implements nfl.dallas.Cowboys {
}
...
public void testMethods() {
Cowboys cowboys = new Cowboys();
cowboys.pass(100,"HailMary");
cowboys.run(100,"Middle");
String s = Cowboys.getStadiumName();
s = nfl.dallas.Cowboys.getStadiumName();
int i = Cowboys.stadiumZipcode;
testReturns();
}
public void testReturns() {
class ReturnTest {
public Cowboys getCowboys() {
return new Cowboys();
}
public nfl.dallas.Cowboys getMoreCowboys() {
return new Cowboys();
}
public FootballTeam getFootballTeam() {
return (FootballTeam) new Object();
}
}
}
}Test クラスの testMethods() メソッドでは、Test クラスの testReturns() メソッドを呼び出しています。マップでこのメソッドが参照されていなくても、または Test クラスが参照されていない場合でも、このメソッドには注釈が付く可能性があります。まず、nfl.dallas.Cowboys がコード マップで参照されているものとします。その場合、Test クラスの先頭近くにある、nfl.dallas.Cowboys または Cowboys を継承または実装する内部クラス定義のため、コード移行ツールは、誤って、testReturns() が nfl.dallas.Cowboys クラスの一部であるものと判断します。その結果、Test クラスの testReturns() メソッドには、Cowboys クラスに対して指定されているクラス レベルの注釈が付けられます。
E-Business Control Center の Portlet Wizard では、Webflow 付きでポートレットを提供するようオプションを選択すると、ポートレットは <webflow-filename>delete</webflow-filename> エントリで定義されます。したがって、Webflow は定義されます。
E-Business Control Center で Webflow を削除し、関連するポートレット エディタ ウィンドウを開くと、Webflow の選択は「なし」と表示されます。ところが、portlet.xml ファイルには <webflow-filename>delete</webflow-filename> エントリが残っています。この状態でポータルにアクセスすると、例外が発生します。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||