表 4 WebLogic Portal フレームワークと開発に関する確認済みの制限事項とその解決策
|
|
|
|
|
結合されたポートレットでユーザ プロファイルの更新が確認できないことがある
管理者がユーザのプロファイルを更新した場合、ユーザは、ログアウトしてログインし直すまでその更新を確認できないことがある。これには、WSRP を使用してリモート プロデューサに送信されたプロパティが含まれる。
解決策 : 更新されたプロファイルをユーザが確認するには、ログアウトしてログインし直す必要がある。
|
|
|
JSF ポートレットでポートレット イベントがサポートされない
バージョン 9.2 では、JSF ポートレットでポートレット イベントがサポートされない。
解決策 : ほとんどの JSF ポートレット イベント処理は、バッキング ファイルと JSF 管理対象 Bean を使用して行うことができる。ブレッドクラム スタイルのイベントの場合、JSF ポートレット 1 (バッキング ファイルを含む) には、一部のユーザ データが送信されるフォームがある。JSF ポートレット 1 のバッキング ファイルは、リクエストからデータを取得して、JSF 管理対象 Bean 内のリストを更新する。次に、JSF ポートレット 2 は、JSF 管理対象 Bean のリストにバインドされた HTML テーブル (JSF タグを使用) データを通じて、このデータのリストを表示する。
|
|
|
9.2 のコンシューマから送信された添付ファイルを 8.1.x のプロデューサで処理できない
WebLogic Portal 8.1.x プロデューサにデプロイされたポートレットをコンシューマで使用している場合は、そのプロデューサでファイルのアップロード処理ができないことがある。この問題は、WebLogic Portal 8.1 SP4 および SP5 で発生する。
解決策 : CR268263 のパッチについて、サポートに確認する。
|
|
|
KeyBootstrap クラスで鍵を生成できない
ドメイン スコープの複数の起動クラスを同時に使用することができないため、BEA コマース機能で構築されたコマース アプリケーションでは、アプリケーション スコープ JDBC プールの使用がサポートされない。
|
|
|
ポートレットの非同期表示が有効な場合は、ポートレットで直接ウィンドウのモードまたは状態を変更できない
WebLogic Portal では、ポートレットの現在のウィンドウの状態とモードを、プログラムによって、または URL に追加されたパラメータを使用してポートレットから変更できる。非同期表示 (AJAX または iframe を使用) が有効な場合は、これらのメカニズムによって一貫性のあるビューがエンド ユーザに表示されない。特に、ポートレットの上に表示されるタイトルバーには、モードまたは状態の変更がすぐに反映されない。
|
|
|
JSF の Apache MyFaces 実装を使用する JSF ポートレットが WebLogic Portal でサポートされない
WebLogic Portal では、JSF アプリケーションをラップするポートレットをサポートする。このリリースの WebLogic Portal では、状態管理に関するいくつかの確認済みの問題のため、JSF の Apache MyFaces 実装がサポートされない。
解決策 : Sun Microsystem の JSF RI を使用する。
|
|
|
プロキシ ポートレットの状態管理 : 8.1.x のコンシューマで、プロデューサのセッション タイムアウトが正しく回復されない
コンシューマが 8.1.x を実行中の結合されたコンフィグレーションの場合、コンシューマがプロデューサのセッション タイムアウトから正しく回復しないことがある。
コンシューマのセッション タイムアウトは、すべてのプロデューサのうち最も小さい正のセッション タイムアウトよりも厳密に少なくする必要がある。たとえば、3 つのリモート プロデューサ RP1、RP2、および RP3 に対応する 3 つのプロキシ ポートレット PP1、PP2、および PP3 がコンシューマ ポータルにあるとする。RP1 にはセッションがなく (セッション タイムアウト = 0)、RP2 には 5 分のセッション タイムアウトがあり、RP3 には 2 分のセッション タイムアウトがある。したがって、コンシューマのセッション タイムアウトは 2 分未満にする必要がある。 すべてのプロキシ ポートレットを別の 1 つのグループに割り当てる。このオプションの欠点は、リモート ポートレットとの状態の共有ができないことである。 最後に、(1) と (2) が実行できない場合は、プロデューサのセッション タイムアウトについては、ユーザがブラウザを閉じてポータルを開き直す必要がある。 |
|
|
オフサイト URL の生成時に非圧縮 URL テンプレートを使用する必要がある
圧縮が有効な Web アプリケーションで、GenericURL、そのサブタイプまたは対応する JSP タグを使用してオフサイト URL (URL を生成するコードの Web アプリケーションでホストされないリソースの URL) を生成する場合は、圧縮が無効な URL テンプレートを指定する必要がある。
GenericURL redirectURL = GenericURL.createGenericURL(request, response);
redirectURL.setDomain("www.yahoo.com");
redirectURL.setPath("/compressedUrl/index.html");
redirectURL.setTemplate("no_compression_template");
ここで、「no_compression_template」は、{url:compression} 擬似トークンを除外する URL テンプレートの名前である。
解決策 : URL 圧縮を使用しない。また、GenericURL を使用してオフサイト リソースの URL を作成しない。
|
|
|
IFRAME ベースのポートレット コンテンツの非同期表示を無効にできない
<render:context> タグまたは AsyncContentContext クラスを使用すると、特定の操作についてポートレット コンテンツの非同期表示を無効にできる。IFRAME ベースの非同期表示の使用時には、このようなメカニズムが正しく機能しない。
解決策 : 非同期表示を無効にするか、または AJAX ベースの非同期表示を使用する。
|
|
|
デフォルトでは、p13n 認証では、認証の失敗または成功のみがレポートされるが、その特定の理由はレポートされない。この機能を使用すると、開発者は、UserLoginControl を使用した認証の失敗時に、元の LoginException を取得できる。この機能を使用するには、システム プロパティ「wlp.propogate.login.exception.cause」を「true」に設定する。これにより、WebLogic Server のサーブレット認証サービスから送出された LoginException が表示される。
|
|
|
実行中のサーバに対してサーバ ポートの変更を行うと、ポータル アプリケーションを再起動する必要がある
実行中のサーバに対してサーバ ポート (HTTP または HTTPS) の変更を行うと、その変更を反映するためには、影響を受けるすべてのポータル アプリケーションを再起動する必要がある。
|
|
|
AJAX ベースのコンテンツの非同期表示で Netui フォームの送信アンカを使用できない
AJAX ベースのコンテンツの非同期表示が有効なポートレットで使用される場合、「formSubmit=true」属性を持つ Netui アンカ タグではフォームが正しく送信されない。フォームを正しく送信するには、以下に示すいずれかの解決策を使用する。
IFRAME ベースのコンテンツの非同期表示を使用する。 Netui ボタン タグを使用してフォームを送信する。 <render:context asyncContentDisabled="true"> を使用して Netui フォームまたは Netui アンカ タグをラップする。 |
|
|
GroupSpace アプリケーションのデプロイメント時に URLTemplate エラーが記録される
GroupSpace アプリケーションのデプロイ時に、ドメイン ログとサーバ コンソールに次のエラー メッセージが記録される。
<Jun 23, 2006 11:27:00 AM MDT> <Error>
<org.apache.beehive.netui.core.urltemplates.URLTemplate> <000000> <Required
token, {url:queryString}, not found in template: {url:path}>
<Jun 23, 2006 11:27:00 AM MDT> <Error>
<org.apache.beehive.netui.core.urltemplates.URLTemplate> <000000> <Required
token, {url:path}, not found in template:
{url:scheme}://{url:domain}:{url:port}>
<Jun 23, 2006 11:27:00 AM MDT> <Error>
<org.apache.beehive.netui.core.urltemplates.URLTemplate> <000000> <Required
token, {url:queryString}, not found in template:
{url:scheme}://{url:domain}:{url:port}>
<Jun 23, 2006 11:27:00 AM MDT> <Error>
<org.apache.beehive.netui.core.urltemplates.URLTemplate> <000000> <Required
token, {url:queryString}, not found in template: {url:path}>
<Jun 23, 2006 11:27:00 AM MDT> <Error>
<org.apache.beehive.netui.core.urltemplates.URLTemplate> <000000> <Required
token, {url:path}, not found in template:
{url:scheme}://{url:domain}:{url:port}>
<Jun 23, 2006 11:27:00 AM MDT> <Error>
<org.apache.beehive.netui.core.urltemplates.URLTemplate> <000000> <Required
token, {url:queryString}, not found in template:
{url:scheme}://{url:domain}:{url:port}>
解決策 : このメッセージは、アプリケーションのデプロイメントには影響しないため、無視してかまわない。
|
|
|
.portlet ファイルが関連付けられていない JSR168 準拠のポートレットのポートレット プリファレンスを管理できない
WebLogic Portal では、JSR168 準拠のポートレット Web アプリケーションを、WSRP プロデューサとして使用可能にすることができる。ただし、そのようなアプリケーションに含まれるポートレットのプリファレンスは、プリファレンス API (javax.portlet.PortletPreferences) または WebLogic Portal Administration Console を使用して直接変更することができない。
解決策 : portlet.xml 内の各ポートレットについて、Workshop for WebLogic を使用して .portlet ファイルを明示的に作成する。
|
|
|
フロート ポートレット内または非同期ポートレット内で使用される PostbackURL が原因で状態が失われる
フロート ポートレット内または非同期ポートレット内で PostbackURL (派生型ではない) を使用すると、ポートレットの状態のさまざまな要素 (表示キャッシュの結果など) が失われる。また、そのようなポートレットの複数のインスタンスでは、状態の共有が開始される。
<render:jspContentUrl> や <netui:anchor> などの、ポートレット タイプにより適した他の URL 生成用メカニズムを使用する。 PortletPresentationContext.getLabel() または PortletBackingContext.getLabel() から返された値を持つ PostbackURL に GenericURL.WINDOW_LABEL_PARAM を直接追加する。 |
|
|
デスクトップ ウィザードで名前を使用してデスクトップ テンプレートを検索できない
デスクトップ ウィザードでは、名前を使用してデスクトップ テンプレートを検索できない。デスクトップ テンプレートをタイトルで検索しようとすると、ウィザードに例外が表示される。
解決策 : [すべて表示] ボタンを使用して、すべてのデスクトップ テンプレートの一覧を表示する。
|
|
|
ユーザのログインまたはログアウトの後に、ポータル アプリケーションでリダイレクトを使用する必要がある
ポータル リクエストの実行中にユーザ ID を変更すると、リモート ポートレットが一貫性のない動作をする場合がある。通常、この問題は、ポータルまたはデスクトップの一部としてユーザのログインとログアウトを行う 1 つのポートレットまたは複数の JSP およびクラスがあるときに発生する。ID を変更すると、ポータルによってロードされるユーザ固有のすべてのデータが無効になることがある (特に、データがログインとログアウトの前にロードされる場合)。リモート ポートレットの場合、そのようなデータにはリモート ポートレットの永続状態が含まれる。ユーザ ID を変更すると、コンシューマ (ポータル) は誤った永続状態をプロデューサに送信することがある。
解決策 : ログインとログアウトの直後に、必ずブラウザ リダイレクトを使用する必要がある。これにより、ポータルによってロードされるリクエストのデータが有効になる。
|
|
|
WebLogic Portal では、カスタマイズされたポータル オブジェクトを使用した既存のポータル Web アプリケーションのコンテキスト ルートの変更がサポートされない。
.portal ファイルをカスタマイズ済みの場合や、デスクトップ用の資格を作成済みの場合は、そのカスタマイズおよび資格を削除しない限り、Web アプリケーションのコンテキスト ルートを変更できない。
|
|
|
訪問者ツール デスクトップ シェルがファイルベースのポータルでの表示時にサーブレット例外を送出する
訪問者ツール デスクトップ シェルを使用するファイルベースのポータルに認証済みユーザがアクセスすると、そのヘッダには「javax.servlet.ServletException : 訪問者ツール メニュー コンテキストの初期化に失敗しました。」と表示される。これは、ポータルおよびその中のポートレットの機能には影響しない。また、ストリーミング モードでポータルにアクセスするときには、この問題は発生しない。
解決策 : Workshop for WebLogic では、ポータル パースペクティブに切り替えて、マージ済みプロジェクト ビューにフォーカスを移す。[ ポータル Web プロジェクト｜visitorTools｜visitorMenu.jsp] に移動し、そこで右クリックして プロジェクトにコピーを選択する。 次に、visitorMenu.jsp を開き、<tp:InitMenuContext id="menuContext"/> という行を探して、その行を <tp:IsStreamingDesktop> という行の下に移動する。
|
|
|
ランタイムで Workshop IDE でルック アンド フィール クロモソームを選択できない
Workshop for WebLogic IDE でルック アンド フィール エディタを使用してルック アンド フィールのクロモソームを選択すると、.chromosome ファイル名の拡張子が .laf ファイルに正しく挿入されない。そのため、実行時にポータル フレームワークでクロモソームを検出できない。
解決策 : .laf ファイルに .chromosome ファイル名の拡張子を含む skinChromosome 属性または skeletonChromosome 属性が格納されている場合は、ルック アンド フィール エディタを使用してその .laf ファイルを編集する。編集が完了したら、XML エディタで .laf ファイルを開き (パッケージ エクスプローラで .laf を右クリックし、[アプリケーションから開く｜XML エディター] を選択)、skinChromosome 属性と skeletonChromosome 属性から .chromosome ファイル名の拡張子を削除し、保存して、ランタイム経由でアクセスする。その他の編集を行わない場合は、XML エディタで .chromosome ファイル名の拡張子を .laf の属性に戻す。
|
|
|
クラスタ デプロイメントで WebLogic Portal Administration Console を使用してサービス管理の変更を保存するときに DeploymentException が発生する
サービス管理で初めて変更を行って保存するときに、stdout に DeploymentException が出力され、WebLogic Portal Administration Console に次のようなエラー メッセージが表示される。
サービスに対する変更を永続化しようとしているときに例外が送出されました : 行動追跡サービス。weblogic.management.DeploymentException: [Deployer:149233]An unexpected error was encountered during the deployment process.
| 注意 : |
この問題が発生するのは、クラスタ環境で WebLogic Portal Administration Console を実行するときだけである。 |
解決策 : 次の手順を実行して、plan.xml を管理サーバから管理対象サーバに手動でコピーする。
サービス管理の最初の変更を保存すると、管理ユーザの接続先であった管理対象サーバおよび管理サーバに plan.xml が作成される。 plan.xml を管理サーバから管理対象サーバにコピーする。たとえば、管理サーバの <domain_home>/servers/AdminServer/upload/<app_name>/plan.xml を管理対象サーバ 2 の <domain_home>/servers/managed2/stage/<app_name>/plan/plan.xml にコピーする。 |
|
|
WebLogic Portal クラスタを操作するために WebLogic Administration Server を実行する必要がある
管理対象サーバが LDAP ロールまたはポリシーの変更を試行しているときに WebLogic Administration Server が停止した場合、WebLogic Server はローカル LDAP の変更を行うが、WebLogic Portal は管理サーバが停止したことを検出できないため、RDBMS ポリシー参照データを更新する。管理サーバは再びオンラインになったときにその変更を伝播しないため、クラスタのポリシーは同期されない。
解決策 : クラスタ化された環境で WebLogic Portal を使用しているときに WebLogic Administration Server が実行中であることを確認する。
|
|
|
ResourceProxyServlet でヘッダがプロキシされない
ResourceProxySerlvet でヘッダがプロキシされるかどうか、およびどのヘッダがプロキシされるかは、静的に指定される。この動作は変更できない。
解決策 : カスタム ResourceHeaderFilter を実装して ResourceProxyServlet によるヘッダのプロキシを制御する。
ResourceHeaderFilter のデフォルト実装は、ResourceProxyServlet でどのヘッダをリソース サーバにプロキシする必要があるかを示すために使用される。この実装は、get、post、host、cookie、および expect というヘッダをブロックする。ポートレット スコープ指定クッキーが送信される。
ResourceProxyServlet の動作をカスタマイズするには、ResourceHeaderFilter インタフェースを実装し、完全修飾クラス名を ResourceProxyServlet の初期パラメータ resourceHeaderFilter として追加し、カスタム フィルタ クラス名を参照するようにする。ResourceHeaderFilter のデフォルト実装は次のとおり。
package com.bea.wsrp.consumer.resource;
import com.bea.wsrp.util.debug.Debug; import com.bea.wsrp.consumer.resource.ResourceHeaderFilter; import com.bea.wsrp.consumer.resource.ResourceHeaders;
import javax.servlet.http.HttpServletRequest; import javax.servlet.ServletContext; import java.util.*;
/** * */ public class DefaultResourceHeaderFilter implements ResourceHeaderFilter { // デバッグ private static final Debug debug =Debug.getInstance(DefaultResourceHeaderFilter.class);
// デフォルトでは、private static final HashSet requestHeadersToSkip = new HashSet(); という要求ヘッダはプロキシされない static { requestHeadersToSkip.add("get"); requestHeadersToSkip.add("post"); requestHeadersToSkip.add("host"); requestHeadersToSkip.add("cookie"); requestHeadersToSkip.add("expect"); }
|
| |
public ResourceHeaders getPassThroughHeaders(HttpServletRequest request, ServletContext context, String url) { ResourceHeaders passThroughHeaders = new ResourceHeaders(); List passThroughValues;
// すべてのヘッダ Enumeration headerNames = request.getHeaderNames(); while(headerNames.hasMoreElements()) { String name = (String) headerNames.nextElement(); if(requestHeadersToSkip.contains(name.toLowerCase())) { continue; }
passThroughValues = new LinkedList(); Enumeration values = request.getHeaders(name); while(values.hasMoreElements()) { String value = (String) values.nextElement(); debug.out("[Sending] " + name + ": " + value); passThroughValues.add(value); } if (passThroughValues.size() > 0) { passThroughHeaders.addHeader(name, passThroughValues); } } return passThroughHeaders; } }
|
|
|
ResourceProxyServlet が取得する静的リソースからブラウザに
場合によっては、この Set-Cookie はコンシューマ セッションを示す Set-Cookie (ブラウザ内に存在) を上書きすることがある。そのような場合は、ブラウザから別の要求がコンシューマに送信されると、セッションは失われる。
解決策 : 通常、プロデューサとコンシューマで異なる CookiePath を設定すると、Set-Cookie が区別され、問題が解決する。この処理ができない場合は、次のシステム プロパティを設定する。
"wlp.resource.proxy.servlet.block.response.headers=true"
これにより、ResourceProxyServlet に対してすべての Set-Cookie 応答ヘッダがブラウザに返されるのをブロックするように指示される。
|
|
|
プロキシ ポートレット属性にログインする時のデータベースに対する余分な呼出しによってパフォーマンスに関する問題が発生する場合がある。
WebLogic Portal 9.2 および 9.2.x には、データベース表示、 PF_PROXY_PORTLET_INSTANCE_V, およびプロキシ ポートレット属性にログインする時のデータベースに対する余分な呼出しを解消するコードはありません。したがって、 8.x から 9.2 または 9.2.xへのアップグレード時ポートレットの表示とともに パフォーマンスのオーバーヘッド が発生される場合があります。
解決策: WebLogic Portal 8.1 では、Oracle のビュー PF_PROXY_PORTLET_INSTANCE_V を使用している場合は、9.2 MP2 のパッチについて BEA カスタマ サポートへ連絡してください。
|
