表 4 WebLogic Portal フレームワークに関する確認済みの制限事項
問題 ID
|
説明
|
CR125007
|
CredentialMBean に編集ツールがない。CredentialMBean が application-config.xml に追加され、プレーンテキストのパスワードを必要とするサービスでパスワードを非暗号化形式でファイル システムに格納する必要がなくなった。
CredentialMBean は、暗号化された「Credential」属性を持つ。この属性は、ApplicationConfigurationMBean (親 MBean) が永続化されるか、または読み込まれると、自動的に暗号化または解読される。
プラットフォーム : すべて
解決策 : 現時点で、CredentialMBean では次の解決策を使用する必要がある。
1. application-config.xml を手動で編集して資格を追加する。
2. Administration Portal を使用してその他の MBean を変更する。これにより、ApplicationConfigurationMBean.persist() が呼び出される。
3. 手順 2 で変更した値を元に戻す。
persist() メソッドが呼び出されたため、プレーンテキストの資格は暗号化されている。
この MBean は、次のようになっている。
<Credential Name="LdapPropertyManager" Credential="password"
Username="uid=SomeUserWithReadPermission,ou=people,dc=beasys,dc=com"/>
|
CR177926
|
ポータルのタイトルに使用した「<」および「>」が正しく表示されない。
「<」と「>」は、ページやポートレットなどのポータル オブジェクトのタイトルに使用すると、ブラウザで正しく表示されない。これは「<」と「>」が、文字どおり表示されるのではなく、解釈されて処理される特殊文字であるためである。その結果、これらの記号を使用したタイトルはブラウザに表示されない。
プラットフォーム : すべて
解決策 : これらの記号は、エスケープすれば使用できる。つまり、< は "<" と入力し、> は ">" と入力する。このように入力すると、タイトルはツール内では "<Title>" のように表示されるが、ブラウザでは <Title> と表示される。
|
CR178588
|
IDE で作成した WSRP プロデューサを削除すると、.portlet ファイルが使用できなくなる。
IDE でプロデューサを追加すると、プロキシ ポートレットに対して .portlet ファイルが生成される。後からプロデューサを削除した場合、プロキシ ポートレットはポータル管理の選択可能ポートレットのリストに表示されなくなるが、.portlet ファイルはまだ存在している。その結果、プロデューサが削除されたために使用できない .portlet ファイルが残る。このファイルは、.portal 内で表示した場合は無効な登録ハンドルを示し、デスクトップに追加した場合は表示されない。
プラットフォーム : すべて
解決策 : 手動でファイルを削除する。
|
CR179773
|
SP2 アップグレード/CM - アップグレードされたアプリケーションで BEA リポジトリに対してライブラリ サービスを有効にすると、エラー メッセージが表示される。
この制限は SP3 で修正されたが、SP2 にはまだ適用される。
8.1 SP2 から 8.1 SP4 または SP2 から SP3 にアップグレードし、リポジトリを管理対象リポジトリにアップグレードしようとすると、「キャッシュ nodePathCache.BEA Repository の取得中にエラーが発生しました 」というエラーが発生する。
プラットフォーム : すべて
解決策 : エラー メッセージは表示されるが、Portal では内部的に nodePathCache が作成される。ただ 1 つ、キャッシュの設定 (ttl、サイズなど) だけが変更できない。キャッシュの設定の変更を行う場合は、app-config.xml に正しいエントリを追加し、アプリケーションを再デプロイする。
次のようなエントリを追加する。
<Cache MaxEntries="50" Name="nodePathCache.<repositoryName>" TimeToLive="6000"/>
|
CR180105
|
起動時に java.io.FileNotFoundException: wsrpKeystore.jks を受け取る。
WebLogic Portal の WSRP 機能を利用するには、wsrpKeystore.jks ファイルが必要である。
Configuration Wizard では、このファイルが管理サーバのドメイン ディレクトリ (サーバのルート ディレクトリの 1 階層上) に配置される。
WebLogic Portal の WSRP 機能を利用するには、これ以外の場所 (サーバのルート ディレクトリの 1 階層上) にファイルを配置することはできない。したがって、Configuration Wizard によって生成される管理サーバのドメインでは、正常に機能する。ただし、NodeManager を使用する場合など、その他の一部のクラスタ コンフィグレーションでは、サーバ ルート ディレクトリが上書きされたとき、または Configuration Wizard を使用することなくドメインが作成されたときには、このファイルがこの場所に存在しないことがある。この場合、サーバの起動時に警告と例外が表示される。
サーバ起動時にエラーの症状を示す、以下の形式のメッセージが表示される。
<Apr 26, 2004 3:10:26 PM MDT> <Warning> <WSRP-Security> <BEA-420802> <There was a problem initializing the identity assertion token provider.>
<Apr 26, 2004 3:10:34 PM MDT> <Info> <Security> <BEA-090093> <No pre-WLS 8.1 Keystore providers are configured for server mC for security realm myrealm.>
また、java.io.FileNotFoundException: wsrpKeystore.jks (システムが指定のファイルを見つけられない) が表示される。
プラットフォーム : すべて
解決策 : サーバのドメインのディレクトリに wsrpKeystore.jks ファイルをコピーする。Configuration Wizard で作成されたドメインからファイルをコピーする。
|
CR180784
|
対象を再選択した後のデプロイ中の Null Pointer 例外。
コンテナ アプリケーションの対象サーバまたはクラスタを変更した後、コンテナ アプリケーションをデプロイしようとすると、サーバ コンソールおよび WSRP コンシューマ Web アプリケーションのログに Null Pointer 例外が出力される。この例外による機能への影響はないので、この例外は無視してかまわない。
プラットフォーム : すべて
解決策 : なし。
|
CR181801
|
サーブレットの応答ラッパーでカスタムの outputstream や writer が使用されていると、ポータルまたはデスクトップを表示できない。
ポータルまたはデスクトップのフィルタ処理に応答ラッパーを持つサーブレット フィルタを使用している場合、その応答ラッパーが getOutputStream() メソッドと getWriter() メソッドをオーバーライドしてカスタムの javax.servlet.ServletOutputStream と java.io.PrintWriter objects を返すと、java.lang.IllegalStateException が表示されることがある。
プラットフォーム : すべて
解決策 : フィルタ処理が必要なコンテンツを IFRAME または別個のブラウザ ウィンドウに表示する。
|
CR183399
|
pageCheckSeconds が設定されている場合、アーカイブ Web アプリケーションに対してポータルのファイル キャッシング ロジックが機能しない。
WebLogic Portal には、.portal ファイルの内部表現をキャッシュする機能があり、この機能によってポータル リクエストの処理を高速化している。ただし、Web アプリケーションがアーカイブとしてデプロイされており、かつ、weblogic.xml 内で pageCheckSeconds が正の値に設定されている場合、このロジックは機能しない。
プラットフォーム : すべて
解決策 : weblogic.xml 内の pageCheckSeconds の値を -1 に設定する。これにより、古い JSP ページのチェックが行われないようになるため、プロダクション モードのデプロイメントではあらゆる場合に有効な設定となる。
|
CR192513
|
credentialMBeanName がコメント解除されている場合、LdapPropertyManager の ConfigurableEntitySystemException が送出される。
LDAP の統合ユーザ プロファイルをコンフィグレーションするときに、LdapPropertyManager で以下の例外が送出される。
com.bea.p13n.property.ConfigurableEntitySystemException: Error reading ldap configuration
プラットフォーム : すべて
解決策 : p13n_ejb.jar ejb-jar.xml ファイル内の LdapPropertyManager のコンフィグレーションが拡張され、LDAP 接続パスワードの暗号化が可能になった。credentialMBeanName 環境エントリは、デフォルトではコメント解除されている。暗号化されたパスワードが必要でない場合は、このセクションをコメントにする。
コメントにしたセクションは、たとえば次のようになる。
<!-- env-entry > <description>The name of the Credential MBean in application-config.xml that will be used to store the principal's username and principal's password. The password will be stored in an encrypted form. This is the principal/credential used to bind to the LDAP server. The password will be decrypted before it is used to bind to the LDAP server. Using this entry will override anything set for the config/principal and config/principalCredential. If this entry and config/principal and config/principalCredential are not specified then anonymous bind will be used.
(このエントリは省略可能)</description> <env-entry-name>config/credentialMBeanName</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>LdapPropertyManager</env-entry-value> < /env-entry -->
暗号化されたパスワードが必要な場合は、セクションをコメント解除した状態のままとし、META-INF/application-config.xml ファイルに追加の LdapPropertyManager 資格セクションを指定する。
<Credential Name="LdapPropertyManager" Credential="password" Username="uid=ldapadministrator,ou=people,dc=beasys,dc=com"/>
|
CR196690
|
ポートレット ウィザードおよび [ポートレットの生成] で、Web アプリケーションに対して有効でないポートレット タイプが選択できる。
ポータル ライブラリ全体ではなく WSRP プロデューサだけがインストールされた Web アプリケーションもある。このような Web アプリケーションでは、[ファイル|新規作成|ポートレット] メニュー項目または右クリック メニューの [ポートレットの生成] のいずれかを使用して、新しい .portlet ファイルを作成できる。両方のアクションでポートレット ウィザード ウィンドウが開く。そのウィンドウには使用可能なポートレット タイプ (JSP/HTML、ページ フロー、Java、Struts、およびリモート) が表示され、その中から選択できる。ただし、WSRP プロデューサのみの Web アプリケーションで動作するのは、ページ フロー ポートレットと Struts ポートレットだけである。
プラットフォーム : すべて
解決策 : WSRP プロデューサのみの Web アプリケーションでは JSP/HTML ポートレット、Java ポートレット、またはリモート ポートレットを選択しない。
|
CR197762
|
別の Web アプリケーションから JSP を組み込むフォーク表示ポートレットが、一貫性のない動作をする場合がある。
ルートの ServletRequest のコンテキスト クラスローダに関するスレッド セーフティの問題により、ポートレットとは別の Web アプリケーションにあるフォーク表示ポートレット内から組み込まれた JSP では、指定されているコンテキスト クラスローダが正しくないため、実行に問題が発生することがある。
プラットフォーム : すべて
解決策 : フォーク表示ポートレットとは異なる Web アプリケーションから JSP を組み込まないようにするか、別の Web アプリケーションから JSP を組み込むポートレットには forkRender を使用しない。
|
CR198438
|
ルック アンド フィールのファイルを使用するとき、[ドキュメント構造] タブが正常に動作しない。
ルック アンド フィールを処理するとき、[ドキュメント構造] タブが正常に動作しないことがある。その結果、CSS のクラス名および属性値がドキュメント構造ツリーに表示されなくなる。この問題が発生するのはごくまれであるが、発生した場合は [ドキュメント構造] タブが使用できなくなる。
プラットフォーム : すべて
解決策 : ルック アンド フィール ファイル (*.laf ) を閉じてから再度開くと、[ドキュメント構造] タブは正常に戻る。
|
CR198827
|
デスクトップの一部であるポートレットにフロート ボタンがある場合、例外または警告が送出される。
ユーザがデスクトップの一部であるポートレット上のフロート ボタンをクリックすると、次のエラー メッセージが記録される。
<BEA-423162> <One or more validation error(s) occurred during parsing /test.portlet. The error(s) were error: The document is not a root@http://www.bea.com/servers/netuix/xsd/portal/support/1.0.0: document element namespace mismatch expected
"http://www.bea.com/servers/netuix/xsd/portal/support/1.0.0";; got "http://www.bea.com/servers/netuix/xsd/jsp/support/1.0.0";;.>
プラットフォーム : すべて
解決策 : なし。このメッセージは無視してかまわない。
|
CR199861
|
render:standalonePortletUrl タグで不正なリンクが作成される (このリンクを使用するポートレットがリモート ポータルによって使用される場合)。
render:standalonePortletUrl タグは、クリックしたときに新しいブラウザ ウィンドウにポートレットを表示するリンクの作成に使用する。ただし、このタグを使用してポートレットをプロデューサにホストした後、リモート ポータルでこのポートレットを使用すると、このリンクでポートレット専用のブラウザ ウィンドウは開かない。
プラットフォーム : すべて
解決策 : 解決策として、コンシューマ サイドに作成されるリモート ポートレットのバッキング ファイルを作成し、ポートレット JSP 内にカスタム コードを作成する。手順は次のとおり。
a. プロキシ ポートレットのバッキング ファイルを作成する。
b. バッキング ファイルの preRender() に次のコードを追加する。
StandalonePortletURL url = StandalonePortletURL.createStandalonePortletURL(request, response); SimpleStateHolder state = new SimpleStateHolder(); state.addParameter("my_url", url.toString()); request.setAttribute(MarkupRequestState.KEY, state);
c. プロデューサ サイドの JSP で、ポートレットをフロート状態にするリンクを生成するために、
render:standalonePortletUrl タグではなく、次のコードを使用する。
<% SimpleStateHolder state = (SimpleStateHolder) request.getAttribute(MarkupRequestState.KEY); String url = (String) state.getParameter("my_url"); %> <a href="<%=my_url%>">Click</a>
|
CR203087
|
プロデューサの環境が別の場所に変更された場合、プロデューサのデータとリモート ポートレットが使用できなくなることがある。
プロデューサを追加してリモート ポートレットを作成すると、プロデューサのレジストリ (WEB-INF/wsrp-producer-registry.xml ) とポータル フレームワークのデータベース テーブルに、格納されたプロデューサのアドレス (プロデューサの WSDL アドレスと、プロデューサの WSDL に記述されているさまざまなポートのアドレス) が保存される。プロデューサを別の環境に移動すると、保存されたこのデータが無効になる場合がある。その場合は、元の場所でプロデューサと通信できないため、ポートレットを使用できないことがある。
プラットフォーム : すべて
解決策 : com.bea.wsrp.consumer.management.producer.ProducerManager を使用してデータベースのエントリを更新できる。この API は、プロデューサ情報を取得して更新するためのメソッドを提供する。
|
CR203935
|
WSRP プロデューサのみの Web アプリケーションでポータルのアップグレードが機能しない。
Service Pack 3 からアップグレードする場合、WSRP プロデューサを持つ Web アプリケーションのライブラリは、自動的には Service Pack 4 に更新されない。そのため、ポートレット ウィザードやその他のサービスから Web アプリケーションと通信しようとしたときに、問題が起きることがある。
アプリケーションのレベルで [インストール|Portal ライブラリの更新] を使用する通常のポータル アップグレード方法では、WSRP プロデューサがインストールされた非ポータル Web アプリケーションを正しく検出できない。さらに、WSRP プロデューサを Web アプリケーションに再インストールしても、ライブラリ ファイルは更新されない。
プラットフォーム : すべて
解決策 : 次のファイルを Web アプリケーションの WEB-INF/lib ディレクトリにコピーする。
<beahome>/weblogic81/portal/lib/netuix/web/netui-adapter.jar
<beahome>/weblogic81/portal/lib/netuix/system/ext/web/struts-ad apter.jar
<beahome>/weblogic81/portal/lib/netuix/system/ext/web/struts-ad apter-html.tld
<beahome>/weblogic81/portal/lib/netuix/system/ext/web/struts-ad apter-naming.tld
<beahome>/weblogic81/portal/lib/netuix/system/ext/web/struts-ad apter-nested.tld
<beahome>/weblogic81/portal/lib/netuix/system/ext/web/struts-ad apter-tiles.tld
<beahome>/weblogic81/portal/lib/wsrp/wsrp-producer.jar
<beahome>/weblogic81/portal/lib/wsrp/adapters/wsrp-jpf-adapter. jar
<beahome>/weblogic81/portal/lib/wsrp/adapters/wsrp-struts-adapt er.jar
サーバが実行中である場合は、WSRP プロデューサである Web アプリケーションを再デプロイする。
アプリケーションのその他の部分は通常の方法でアップグレードする必要がある。
|
CR204478
|
ポータル ツリーの最適化がオンになっていると、非表示ポートレットの onDeactivation ポートレット イベントが動作しないことがある。
.portal ファイル内の「ツリー最適化」フラグがオンになっている場合、指定されたリクエストで一部の非表示ポートレットが処理されないことがある (非表示ポートレットとは、指定されたリクエストに対して表示されないページ上に存在するポートレットである)。これは、ポートレットの非アクティブ化イベント (onDeactivation) を捕捉しようとした場合に問題になることがある。ポートレットは非アクティブ化されると非表示になるので、システムがポートレットの非アクティブ化イベントを開始するためにポートレットを処理することはない。
プラットフォーム : すべて
解決策 : 最も安全な代替策は、問題のポータルに対してツリー最適化を false に設定することである。ただし、ツリーを最適化する必要がある場合は、次の解決策を実施できる。非アクティブ化イベントを捕捉したい各ポートレットについて、ダミーのイベント ハンドラを定義する (たとえば、event = "[任意の文字列]" を指定してカスタム イベント ハンドラを作成し、"Only If Displayed" プロパティを false に設定する)。これによって、ポートレットは非表示かどうかにかかわらず、システムで処理される。
|
CR206920
|
.portlet ファイルからポートレット プリファレンスがデフォルトで再ロードされない。
Service Pack 4 より前は、サーバがバウンスまたは再デプロイされた場合は常に、.portlet ファイル内のプリファレンスがデータベース内のプリファレンスをオーバーライドし、管理者によるポートレット プリファレンスの追加および変更はサーバ再起動時に失われていた。
新しいオプションを使用すると、サーバ再起動時にポートレット プリファレンスを再ロードする方法を制御できる。このコントロールは、WEB-INF/netuix-config.xml ファイルで「propagate-preferences-on-deploy」要素の「master」属性を使用して実装する。
master 属性に指定できる値は次のとおり。
file
以前のバージョンと同じ動作を指定する。ファイル システム内のプリファレンスが常に優先される。既存の動作を保持するには、この値を選択する。
database
再起動時には、データベース内の値が常に優先される。初回起動時には、.portlet ファイルからデータベースに値が読み込まれる。
both
属性が指定されていない場合のデフォルトの動作。.portlet のプリファレンスがデータベースのプリファレンスとマージされる。このとき、データベースの値が .portlet ファイルの値よりも優先される。
次の例は、属性の値を both に指定した要素を示している。
<customization>
<enable>true</enable>
<propagate-preferences-on-deploy propagate-to-instances="true" master=" both "/> <reload-database-on-redeploy reload="false"/> </customization>
|
CR218066
|
WebLogic Portal 8.1 (Service Pack 4) で、ツリー最適化がオンになっていると、ブックの [デフォルト ページに戻る] 属性が正常に動作しない。
移動先 URL の対象であるブックの [デフォルト ページに戻る] 属性が true に設定されている場合は、そのブックのデフォルト ページが表示されるはずだが、表示されない。
プラットフォーム : すべて
解決策 : この CR は、ブックがネストされていて、メイン ブックの直接の子がブックである場合のみを対象とし、[デフォルト ページに戻る] は、ブック間の移動にのみ適用され、ブック内の移動には適用されない。次に、各ページにブック 2 への URL が設定されたポートレットを含む単純なポータルの階層を示す。
メイン ブック - ブック 2 がデフォルト ブック
ブック 2 - デフォルト ページに戻る = true、デフォルト ページ = ページ 2
ページ 2
ページ 3
ブック 3
ページ 4
ページ 5
このポータルを表示すると、ブック 2 とページ 2 が表示される。
1. ユーザがページ 3 をクリックする (デフォルト ページから移動)。
2. ユーザがブック 3 をクリックする (ページ 4 が表示され、別のブックに移動)。
3. ユーザがブック 2 の URL をクリックすると、ページ 2 が表示される。
ページ 2 がブック 2 のデフォルトであるため、これは想定されたとおりの動作であり、ブック 2 の最後のアクティブなページはページ 3 である。
このポータルを表示すると、ブック 2 とページ 2 が表示される。
1. ユーザがページ 3 をクリックする (デフォルト ページから移動)。
2. ユーザがブック 2 の URL をクリックすると、ページ 3 が表示される。
これは、ページ 3 が同じブック内にあり、デフォルトに戻る設定が適用されないために発生する。
|
CR218066 (続き)
|
次のようにメイン ブックの子がページである階層では、デフォルトに戻る設定は適用されない。
メイン ブック - ページ 1 がデフォルト ページ
ページ 1
ブック 2 - デフォルト ページに戻る = true、デフォルト ページ = ページ 2
ページ 2
ページ 3
ページ 6
ブック 3
ページ 4
ページ 5
この階層では、ユーザはブック 2 の最後のアクティブなページに戻る。
|
CR223724
|
キャンペーン - キャンペーン スキーマ (目標) にエラーが存在する場合に例外がコンソールに表示されるようにする。
目標のあるキャンペーンの作成時に、xsd が必要とする完全な XML が生成されない。以下の行を手動で追加する必要がある。
<ca:ad-id xmlns:ca="http://www.bea.com/servers/campaign/xsd/campaign/1.1.1";>
</ca:ad-id>
ユーザがこの行を手動で追加しなかった場合、例外が送出されるが、コンソール上には表示されない。目標は有効にならないため、非常に紛らわしい動作である。
プラットフォーム : すべて
解決策 : なし。
|
CR225885
|
RDBMS 認証プロバイダで、XA ドライバ、マルチプールおよびドライバ レベルのロード バランシングがサポートされない。
XA ドライバを使用すると、サーバが起動しない。
プラットフォーム : すべて
解決策 : ロード バランシングはサポートされていないため、RDBMS 認証プロバイダに非 XA ドライバを使用する。
|
CR226791
|
CM タグにデフォルトのコンテンツ リポジトリ選択肢が提供される。
WebLogic Portal 7.0 には、コンテンツ管理タグで使用可能な「contentHome 」パラメータがある。このパラメータで、どのコンテンツ リポジトリをクエリで使用するかを指定できる。WebLogic Portal 8.1 では、このパラメータは Java API (たとえば、ContentHelper の homeName パラメータ) で使用できるが、非推奨であり、JSP タグでは無視される。
また、リポジトリ パラメータが指定されていない場合、タグではコンテンツ リポジトリを指定できない。デフォルトの動作では、すべてのリポジトリが集約される。
プラットフォーム : すべて
解決策 : Portal 8.1 Service Pack 5 では、「searchPaths 」というオプションのパラメータが <pz:contentQuery> および <cm:search> タグに追加された。このパラメータを使用して、コンテンツ クエリに使用する特定のリポジトリを指定できる。Service Pack 5 では、「-Dcm.default.search.path= 」システム パラメータを使用してカンマ区切りのデフォルト検索パス リストを設定する機能も追加されている。デフォルト検索パス リストを指定を設定する場合、<pz:contentQuery> および <cm:search> タグで、「searchPaths 」パラメータが指定されていない場合にこのパラメータを使用する。
|
CR227092
|
コマース コンポーネント Price Engine によりデータベースが圧迫される。
割引が使用されると、その使用カウントがデータベース内でインクリメントされる。割引の使用が無制限の場合、ユーザは使用回数を追跡しない。
プラットフォーム : すべて
解決策 : システム プロパティ track.unlimited.discount.usage=false を設定し、使用制限が「UNLIMITED」になっている割引の使用カウントの追跡を無効にする。
|
CR228941
|
最初にアプリケーションがアクセスしたときに、追加の Datasync リポジトリが作成される。
ルール リポジトリは、最初にルールがアクセスされるまで初期化されない。この初期化プロセスには時間がかかり、この間アプリケーションは使用できない。
プラットフォーム : すべて
解決策 : RulesetPersistenceManager EJB の記述子の次の行を変更する。
<initial-beans-in-free-pool>0</initial-beans-in-free-pool>
これを次のように変更する。
<initial-beans-in-free-pool>1</initial-beans-in-free-pool>
これにより、ルール リポジトリはサーバの起動時に初期化される。
|
CR230071
|
必須ページが、ユーザによって削除される可能性がある。
WebLogic Portal 7.0 では、ポータル管理者は、必須ページのページ属性を設定し、ユーザのカスタマイズによって特定のページが削除されることのないように指定できる。WebLogic Portal 8.1 では、ユーザが訪問者ツールを利用して、アクセス権限のあるページすべてを削除できるようになったため、この機能を直接使用することはできない。
プラットフォーム : すべて
解決策 : WebLogic Portal 7.0 と同様の機能を実行するには、PortalCustomizationManager インタフェースの removePlaceable() メソッドを使用する。これにより、ユーザが必須ページを削除できないようにすることができる。必須ページにこの実装を適用する場合は、次の点に留意する必要がある。
各ページに、少なくとも 1 つの資格を設定する必要がある。ページの作成時は資格が存在せず、デフォルトでそのページのすべての特権が付与される。removePlaceable() メソッドは、削除されるブックまたはポートレットを含むページの更新資格をチェックする。
SP5 の訪問者ツールのコードは PortalEntitlementHelper クラスを呼び出すため、ページの資格を取得する手段としてこのクラスを使用することが推奨される。
boolean isAllowed = PortalEntitlementHelper.checkPageDelete(new
CustomizationContext(request.getLocale(), request), <page_definition_id>)
この場合、呼び出しを行ってから、その結果に基づいて分岐するように訪問者ツールのコード内にチェックを追加する必要がある。
将来のリリースで、このタスクの実行手段をより堅牢なものにする。
PortalCustomizationManager インタフェースの詳細については、http://e-docs.bea.com/wlp/docs81/javadoc/index.html の WebLogic Portal Javadoc を参照。
|
CR235701
|
PortalContextAdapter の記述が threadSafe 属性を無視する。
threadSafe 属性をポートレット内で false に設定していても、リモート ポートレットでは常に true として扱わる。
プラットフォーム : すべて
解決策 : なし。
|
CR235832
|
Propagation ツールを使用すると、「Verbose log could not be set, parent folder does not exist」というエラーが発生する。
propagation.war の web.xml 内の oamDataFilesystemPath 要素はデフォルトで d:/propagation/81xDomain/inventories に設定されている。D ドライブが存在しない場合、次のような例外が送出される。
<Error> <InventoryServices> <machinename> <portalServerFrom> <ExecuteThread: '13' for queue: 'default'> <weblogic> <> <000000> <Verbose log could not be set, parent folder does not exist. logFile: d:\propagation\81xDomain\inventories\view_verbose_D13_H9_M42_S34.log>
次のような場合に、このような例外が送出される。
プラットフォーム : すべて
解決策 : propagation.war の web.xml ファイルの oamDataFilesystemPath 設定を既存のドライブに変更する。
Windows システムでの変更例 :
<context-param>
<param-name>oamDataFilesystemPath</param-name>
<param-value>c:/propagation/81xDomain/inventories</param-value>
<description>Base folder path for runtime data, such as inventory exports.</description>
</context-param>
UNIX システムでの変更例 :
<context-param>
<param-name>oamDataFilesystemPath</param-name>
<param-value>/opt/propagation/81xDomain/inventories</param-value>
<description>Base folder path for runtime data, such as inventory exports.</description>
</context-param>
|
CR236023
|
ポータル アプリケーションのコマース サービスを有効にした後、<cat:catalogSelector> タグが機能しない。
既存のポータル アプリケーションに対してコマース サービスを有効にした場合、<cat:catalogSelector> タグを使用するために必要なファイルの一部がこのインストールに含まれていない。このコードは、<application>/META-INF/data/catalogselectors/GlobalCatalogSelectors にある GlobalCatalogSelectors.rls ファイルを見つけることを想定している。また、8.x 製品ラインには、GlobalCatalogSelectors.rls ファイルを作成するためのツールは用意されていない。
プラットフォーム : すべて
解決策 : 参照用に、作業中の GlobalCatalogSelectors.rls ファイルの例を次に示す。
<?xml version="1.0" ?>
<cr:rule is-complete="true"
xmlns="http://www.bea.com/servers/p13n/xsd/expression/expressions/2.1.1"
xmlns:collection="http://www.bea.com/servers/p13n/xsd/expression/collection/1.0.1"
xmlns:cq="http://www.bea.com/servers/p13n/xsd/content/query/1.1.1"
xmlns:cr="http://www.bea.com/servers/p13n/xsd/rules/core/2.1.1"
xmlns:math="http://www.bea.com/servers/p13n/xsd/expression/math/1.0.1"
xmlns:ss="http://www.bea.com/servers/p13n/xsd/expression/schema-support/2.1.1"
xmlns:string="http://www.bea.com/servers/p13n/xsd/expression/string/1.0.1"
xmlns:lit="http://www.bea.com/servers/p13n/xsd/expression/literal/1.0.1"
xmlns:wlcs="http://www.bea.com/servers/p13n/xsd/rules/extensions/2.1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/servers/p13n/xsd/rules/core/2.1.1 rules-core-2_1_1.xsd http://www.bea.com/servers/p13n/xsd/rules/extensions/2.1.1 rules-extensions-2_1_1.xsd">
<cr:name>test</cr:name>
<cr:description />
|
CR236023 (続き)
|
<cr:conditions>
<multi-and>
<greater-than>
<wlcs:literal>
<wlcs:now />
</wlcs:literal>
<wlcs:literal>
<wlcs:time-instant>1970-01-01T00:00:00-07:00</wlcs:time-instant>
</wlcs:literal>
</greater-than>
</multi-and>
</cr:conditions>
<cr:actions>
<wlcs:add-catalog-query-object>
<wlcs:expression>price > 50</wlcs:expression>
<wlcs:max-results>100</wlcs:max-results>
<wlcs:catalog-manager-name>portalApp.BEA_commerce.CatalogManager</wlcs:catalog-manager-name>
</wlcs:add-catalog-query-object>
</cr:actions>
</cr:rule>
|
CR239172
|
ページフロー ポートレットで preRender フォーク表示を有効にすると、コンテンツの表示エラーが発生する。
8.1 SP5 の新機能により、ポートレットの preRender ライフサイクル フェーズを個別のスレッドで実行できる。これは、preRender フォーク表示とも呼ばれる (詳細については、e-docs を参照)。Service Pack 5 リリースの時点では、この機能はページフロー ポートレットに対して正常に動作しない。ページフロー ポートレットの preRender フォーク表示を有効にすると、ポートレットのコンテンツの表示が失敗する。つまり、ポートレット フレームとタイトル バー (存在する場合) は表示されるが、コンテンツは表示されない。現在この問題に取り組み中であり、パッチが完成したらすぐにこの CR に記載される。
プラットフォーム : すべて
解決策 : ページフロー ポートレットでは preRender フォーク表示を使用しない。
|
CR225408
|
8.1 SP6 で、優先順序の問題によりコンテンツ クエリ式が誤って生成される。
式 (a && (b || c) が、(a && b || c) として評価/実行される。コンテンツ クエリ式の実行時に優先順序が維持されない。
プラットフォーム : すべて
解決策 : この問題は、8.1 SP6 で修正され、コンテンツ クエリ式の実行時に優先順序が維持されるようになった。8.1 Service Pack 5 以前と同様に式が評価されるように、この修正を無効にするシステム プロパティが追加された。
-Denable.content.rule.fix=true
|
CR254373
|
WSRP 要求から次の WSRP 要求に、要求パラメータが暗黙的に伝播されなくなった。
この問題が影響するのは、CR 254373 のパッチを適用したユーザのみ。
CR254373 の修正を適用する前は、ポータル フレームワークにより、すべての要求パラメータが WSRP navigationState URL に自動的に追加される。これは、WSRP 仕様違反であり、URL が長くなりすぎるため問題が発生した。CR254373 によってこのバグは修正されたが、修正が適用された後、一部のユーザによるページフローの一般的な使用例が失敗するようになった。この使用例では、ページフロー アクションへのフォームの送信、result.jsp へのアクション転送を行い、そこで要求からフォーム コンテンツを取り出して表示する。これは、標準のページフローでは機能するが、フォームの送信とその後の結果の表示にはコンシューマからプロデューサへの 2 つの要求が必要 (ただし、ユーザがコンシューマと対話するときは 1 つの要求に見える) なので、WSRP コンシューマ ポートレットを介してページフローにアクセスすると失敗する。コンシューマからプロデューサへのフォームの送信は performBlockingInteraction() 呼び出しで処理される。この呼び出しが完了すると、続いてコンシューマが getMarkup() 要求をプロデューサに送り、プロデューサは result.jsp ページのマークアップを返す。ただし、要求から次の要求へ要求パラメータが暗黙的に伝播されなくなったので、getMarkup() 要求の処理時にはフォーム パラメータは存在しない。上記のページフローは、この問題を表す一例だが、performBlockingInteraction() 呼び出しが行われるすべてのケースに当てはまる。
プラットフォーム : すべて
解決策 : これは解決策とはいえないが、この機能を実装するための適切な方法である。必要なのは、要求に保持するパラメータを実装者が明示的に伝播することだけである。上記のページフローの例では、実装を修正できる簡単な解決策が 2 つある。1 つ目の解決策は、送信されたフォームを受信したページフロー アクションが返す Forward オブジェクトにフォームを明示的に含めることで渡すことができる。これは、netui ActionForm オブジェクトを使用して指定できる。または、Forward オブジェクトに pageInput として個々のパラメータ名と値のペアを含めることができる。これで、results.jsp は、使用されるメソッドに適した方法で項目を取得する。もうひとつの解決策は、ページフローの状態の一部として目的のパラメータを保持すること。つまり、フォームを受信したアクションが、ページフローで ActionForm または要求から目的のパラメータを取得し、値をインスタンス変数に割り当て、ゲッターを使用してそれらの値にアクセスできるようにする。これで、result.jsp は、それらのゲッターを使用して必要な値にアクセスできる。
|