© Copyright International Business Machines Corporation 2006. All rights reserved.
サンプル・ギャラリーからサンプルのポータル・プロジェクトをインポートするか、または「新規ポータル・プロジェクト」ウィザードを使用してポータル・プロジェクトを作成すると、「問題」ビューにリンク切れに関する警告メッセージが表示されます。
Rational® Developer のこのバージョンでは、Portal Designer は HTML、cHTML、および WML での表示しかサポートしません。インポート・プロジェクト内でページまたはラベル用にサポートされるその他のマークアップ言語を指定した場合、これらのマークアップ言語は Rational Developer によって表示用にサポートされますが、編集はできません。これらのマークアップ言語は、「プロパティー」ビューに表示されません。
カラー・パレットをページに割り当てない限り、 WebSphere® Portal 6 ではデフォルトのカラー・パレットが使用されます。しかし、Portal Designer では、カラー・パレットが指定されていないと、 デフォルトのパレットの代わりに祖先ページのカラー・パレットが使用されます。
「新規ポータル・プロジェクト」ウィザードで、ポータル・サーバーのバージョンを選択しても、自動的にはターゲット・ランタイムは更新されません。ポータル・サーバー・バージョンとターゲット・ランタイム設定は、手動で同期させる必要があります。例えば、ポータル・サーバー・バージョンの 6.0.0.x には WebSphere Portal v6.0 ランタイムを選択し、ポータル・サーバー・バージョンの 5.1.0.x には WebSphere Portal v5.1 を選択する必要があります。ターゲット・ランタイム・バージョンがポータル・バージョンと同期していない場合は、 ポータル・サーバーが、ポータル・プロジェクトをデプロイするときに破損しているか、使用不能になっている可能性があります。
WebSphere Portal v6.0 では、スタイル・ダイアログで styles.jsp または styles_theme.jspf のような CSS コンテンツ・タイプ JSP ファイルを編集すると、JSP 式がダイアログ上に表示される場合があります。これらの JSP 式はダイアログ上では変更できません。CSS Designer ソース・パネルで変更する必要があります。
JSR168 Faces ポートレットでは、以下のツールのいずれかを使用して Faces JSP にサービス・クライアントを生成した場合、生成されたページ・コードは WebSphere Portal の 6.0 でも、5.1 でも正常に機能しません。 影響を受けるツールには以下のものがあります。
- ページ・データ・ビュー
- Java™ Bean (メソッド呼び出しを使用)
- Web サービス
- EJB Session Bean
- パレット・ビュー
- Java Bean (メソッド呼び出しを使用)
- Web サービス
- EJB Session Bean
- 「Page Designer」コンテキスト・メニューまたは「ウィンドウ」メニューから、「挿入」->「データ」
- Java Bean (メソッド呼び出しを使用)
- Web サービス
- EJB Session Bean
これは、以前のものとは異なる jsf-portletbridge.jar に含まれている JSR168 Faces ポートレット・ランタイムの新規実装に原因があります。
新規実装では、Faces JSP のページ・コード Bean は、 要求スコープの管理 Bean として宣言される場合、ポートレットのアクション・フェーズとレンダリング・フェーズ間では永続しません。生成された Web サービス・クライアント・コードでは、 ページ・コード Bean は、アクション・フェーズで Web サービスの結果をキャッシュするために使用されます。しかし、要求スコープ内にあるので、新規インスタンスがレンダリング・フェーズ時に作成されます。したがって、キャッシュされた結果は失われます。
2 つのソリューションがあります。
- Bean をセッション・スコープに置きます (これは、faces-config.xml に構成されます)。 これは、構成ファイルの 1 行を変更するほどに簡単です。
- これは、#1 ほど簡単ではありませんが、サービス・クライアントを JSR168 ポートレットに実装するための推奨方法です。JSR168 ポートレット・プログラミングのベスト・プラクティスに従い、優れた「戻る」ボタンを使用可能にし、ブック・マーキングをサポートします。
- アクション・フェーズで Web サービスを呼び出す必要がある場合、例えば、サービス結果により異なるターゲット・ページがナビゲートされる場合は、 結果がキャッシュされる方法を変更する必要があります。ページ・コード Bean のローカル変数を使用する代わりに、レンダリング・パラメーターまたはポートレット・セッションを使用します。レンダリング・パラメーターの使用は、文字列値しかサポートしていないが、アクション・フェーズからレンダリング・フェーズへ情報を渡すための推奨方法です。結果が複合型の場合は、代わりにポートレット・セッションを使用する必要があります。
- 以下は、ページ・コード Bean の JSF アクション・メソッド内からレンダリング・パラメーターへ値を設定するサンプルのスニペットです。
PortletResponse response = (PortletResponse)getFacesContext().getExternalContext().getResponse();
((ActionResponse)response).setRenderParameter("resultValue", resultValue);
- 以下は、ページ・コード Bean の JSF アクション・メソッド内からポートレット・セッションへ値を設定するサンプルのスニペットです。
PortletRequest request = (PortletRequest)getFacesContext().getExternalContext().getRequest();
request.getPortletSession().put("resultValue", resultValue);
- あるいは、アクション・フェーズ時にサービスを呼び出す必要がない場合は、 Web サービスの結果 Bean に対する getter メソッドへのサービス呼び出しを遅らせることができます。 JSF アクション・メソッドでは、入力値をレンダリング要求パラメーターに置くか (文字列の場合)、 または、入力値をポートレット・セッションに置きます (複合型の場合)。 次に、入力値は、サービスの呼び出しに使用することができるように、Web サービスの結果 Bean の getter メソッドから取得します。
- 以下は、ページ・コード Bean の JSF アクション・メソッド内のレンダリング・パラメーターに入力値を設定するサンプルのスニペットです。
PortletResponse response = (PortletResponse)getFacesContext().getExternalContext().getResponse();
((ActionResponse)response).setRenderParameter("inputValue", inputValue);
- 以下は、結果に対する getter メソッド内の入力値を取得するサンプルのスニペットです。
PortletRequest request = (PortletRequest)getFacesContext().getExternalContext().getRequest();
String inputValue = request.getParameter("inputValue");
- レンダリング・パラメーターを使用してレンダリング・フェーズへ情報を渡すことには、ブラウザーの「戻る」ボタン・サポートとブック・マーキング・サポートの利点が加わることに注目してください。
ポータル・プロジェクトをインポートするときに、 「以下のワークスペース・ファイルはエディターと不整合です。エディターをワークスペース・コンテンツで更新してください」という質問メッセージ・ボックスが表示されます。「はい」をクリックします。
ポートレット・アプリケーション ID は、JSR 168 仕様に準拠したオプションですが、 Rational® Developer は ID のないポートレットを正しくは公開しません。 Rational Developer は、これらの ID のないポートレットを生成しません。別のソースからポートレットをインポートした場合は、ポートレットを作成することは可能です。この問題を回避するには、プロジェクトのポートレット配置ディスクリプターを開き、ソース・タブにポートレット・アプリケーション ID を追加します。例えば、次のようになります。
<portlet-app xmlns=... version=... xmlns:xsi=... xsi:schemaLocation=... id="ENTER_YOUR_ID_HERE">
...
</portlet-app>
サーバーの実行中にサーバー状態が停止済みとして検出される場合は、 初めに、SOAP/RMI コネクター・ポートが正しく、サーバー・エディターで使用している WebSphere セキュリティー・クレデンシャルが正しいことを確認します。それらに誤りがある場合、サーバー状態は始動済みとして検出されません。 それらが正しく、かつサーバー状態が停止済みの場合は、 WebSphere Application Server v6.1 と WebSphere Portal v6.0 の共存におそらく問題があります。
最も一般的なシナリオは、WebSphere Application Server 6.1 サーバーを ローカル・マシンにインストールし、新規のワークスペースで始動するというものです。この新規ワークスペースでは、WebSphere Application Server 6.1 サーバー・インスタンスが自動的に作成および初期化されて、 その結果、Portal 6.0 の状態検出が正常に機能しないようになります。また、WebSphere Application Server v6.1 サーバーを作成し、さらに Portal 6.0 サーバーを作成した場合もこのようになります。
ソリューションは、Rational 製品を同じワークスペースを使用して再開することです。その場合、Portal 6.0 サーバー・インスタンスは、WebSphere Application Server 6.1 サーバーが初期化されていない、つまりその状態が停止済みや始動済みではなく、ブランクのままである限り、正常に機能するはずです。
マイ・ポータル・プロジェクトを実行するか、または Portal 6.0 へデプロイすると、ポートレットがページに表示されません。この問題の影響を最小限にするために、完全なデプロイメントが不要であれば、 構成のみのデプロイメントを使用します。
この問題が発生した場合は、すべてのポートレットをデプロイするのではなく、ポータル・プロジェクトの構成のみのデプロイメントの実行を試みてください。 これにより、通常の場合、ポータルがポートレットを再び正しくレンダリングできるようになります。
新規のビジネス・プロセス・メッセージを作成する場合に、WSDL ファイルが文書リテラル・スタイルであれば、入出力のメッセージング名がウィザードの第 2 ページに表示されない可能性があります。その場合でも、それらを選択してメッセージの詳細をウィザードの右側に表示できます。メッセージ名がウィザードに表示されなくても、生成されたコードは正しいです。
連携ウィザードを使用してソースまたはターゲット・ポートレットを作成し、さらに JSR 168 ポートレット・プロジェクトに複数のポートレット・タイプ (基本ポートレットや Struts ポートレットなど) が含まれている場合は、 ウィザードのデフォルト・アクション・パラメーターに誤りがある可能性があります。
基本ポートレットおよび Faces ポートレットでは、 デフォルト・アクション・パラメーターは ACTION_NAME_PARAM になりますが、異なる値を選択することもできます。
Struts では、アクション・パラメーターは spf_strutsAction でなければなりません。
これらは、タスク・ページ・コンテナーの固有名用のデフォルト値です。
WebSphere Portal v6.0: ibm.portal.MyTasks
WebSphere Portal v5.1: wps.MyTasksPortal Designer で、上記のものとは異なる固有名を持つ別のページを使用する場合、デプロイメントの後では、そのページは WebSphere Portal のタスク・ページ・コンテナーのページとして認識されません。
回避方法: デプロイメントの後、以下のステップを使用して、マイ・タスク・ポートレットの TaskPageContainerUniqueName パラメーターの値を変更します。
1. 「管理」> 「ポートレット管理」>「ポートレット」の順に開きます。
2. マイ・タスク・ポートレットの場合は、 「ポートレットの構成 (Configure portlet)」ボタンをクリックします。
3. TaskPageContainerUniqueName パラメーターの場合は、「編集」をクリックします。
4. 以下の値を使用して、Portal Designer の新規の固有名に値を変更します。WebSphere Portal v6.0: ibm.portal.MyTasks
WebSphere Portal v5.1: wps.MyTasks
5. 「OK」をクリックします。
ポータル・プロジェクトが Rational Developer 6.x から Rational Developer 7.0 のワークスペースへマイグレーションされた場合は、 NoModuleFileException のデプロイメント障害の原因となる可能性があります。これが発生した場合、以下の手順に従って問題を訂正します。
- この手順では、失敗したポータル・プロジェクトのデプロイメント操作から、「wps」EAR プロジェクトが既に生成されていると仮定します。
- 新しく生成された EAR プロジェクトの application.xml を開きます。
- application.xml の内容が、以下のようになっていることを確認してください。
<module id="WebModule_1163447032109">
<web>
<web-uri>wps.war</web-uri>
<context-root>wps</context-root>
</web>
</module>
<module id="WebModule_WSRP">
<web>
<web-uri>wps_facade.war</web-uri>
<context-root>/wsrp</context-root>
</web>
</module>
<module id="EjbModule_1">
<ejb>wp.scheduler.ejb.jar</ejb>
</module>
<security-role id="SecurityRole_1">
<description>Everyone in the enterprise.</description>
<role-name>Everyone Role</role-name>
</security-role>
<security-role id="SecurityRole_2">
<description>All Authenticated users in the enterprise.</description>
<role-name>All Role</role-name>
</security-role>
<security-role id="SecurityRole_3">
<description>No users in the enterprise.</description>
<role-name>No Role</role-name>
</security-role>
- より詳しく見ると、内容は以下のようになっています。
- コンテンツ・ルート値が「wps」に設定された wps.war の Web モジュール定義が複数含まれています。
- コンテンツ・ルート値が「wps」に設定された Web モジュール定義が複数含まれていません。
- コンテンツ・ルート値が /wsrp に設定された wps_facade.war の Web モジュール定義が含まれています。
- wp.scheduler.ejb.jar の EJB モジュール定義が含まれています。
- 「Everyone Role」、「All Role」、および「No Role」に対するセキュリティー・ロール定義が含まれています。
- 保管して、再公開します。
WebSphere Portal 6.0 の出荷済み jsf-ibm.jar のバージョンが古いため、クラス・ローダー・モードがポートレット Web モジュールで PARENT_FIRST に設定されている場合は、 一部の JSF コンポーネントがポートレットで正しくレンダリングされません。 これは、クラス・ローダー・モードが PARENT_FIRST に設定されている場合、 WebSphere Portal 6.0 の jsf-ibm.jar が、ポートレット Web モジュールに含まれていたコピーの代わりに使用されるためです。
URL (http://www.ibm.com/jsf/html_extended) に対応する、jsf-ibm.jar のコンポーネントのみが影響を受けます。Faces IBM ポートレットと Faces JSR168 ポートレットの両方が影響を受けます。
ポートレット Web モジュールのクラス・ローダー・モードは、 以下の状態では PARENT_FIRST に設定されます。したがって、変更が必要になります。
この問題を回避するには、 ポートレット・プロジェクトを含む EAR プロジェクトで application.xml ファイルを開き、さらに「デプロイメント」タブを開きます。「アプリケーション」セクションで、EAR とポートレット・プロジェクトを表示するツリーを見つけてください。ポートレット・プロジェクトを選択し、「クラス・ローダー・モード」を「PARENT_FIRST」から「PARENT_LAST」へ変更します。ターゲット・サーバーで変更を有効にするには、再度、アプリケーションを公開する必要があります。
- ポートレットが Rational Developer v7 によってデプロイされる場合
- EAR を使用してポートレットが WebSphere Application Server に先にインストールされ、 次に xmlAccess コマンドを使用して WebSphere Portal に構成される場合
WebSphere Portal 管理ページで、または xmlAccess コマンドを使用して、ポートレットが WAR を使用する WebSphere Portal に直接インストールされている場合は、 クラス・ローダー・モードは既に PARENT_LAST に設定されています。この場合、ポートレットは何も対策しなくとも正常に機能します。
Rational Developer 6.x を使用して作成されたポータル・プロジェクト 5.1.0.1 をプロジェクト交換を使用して Rational Developer 7.0 のワークスペースへインポートすると、 「WebSphere Portal v5.1 テスト環境での実行」が失敗する場合があります。
回避方法: 以下のステップを使用して .portalsettings ファイルの内容を変更します。
1. 「ウィンドウ」 >「パースペクティブを開く」>「その他...」を開きます。
2. 「パースペクティブ」ダイアログで、リソースを選択して「OK」をクリックします。
3. ナビゲーター・ビューに、ポータル・プロジェクトを展開します。
4. .portalsettings ファイルを選択して、テキスト・エディターで開きます。
5. 以下を挿入します。
<?xml version="1.0" encoding="UTF-8"?>
<portalSettings>
<portal-version version="5.1.0.1"/>
<portlets-ear-project portlets-ear-project-name=""/>
<process-integration mytaskspage-uniquename="wps.MyTasks"/>
</portalSettings>
Web デベロッパー (advanced) は、「ポータルのインポート」ウィザードと、ポータルおよびポートレットのサンプル (サンプル・ギャラリーからの) を表示するには機能をオンにする必要があります。機能を使用可能にするには、「ヘルプ」>「ようこそ」と移動し、「ようこそ」で「ロールを有効にする」ボタンをクリックします。このボタンは、画面の隅にあります。次に、ロール「Web デベロッパー (advanced)」を選択して、これをオンにします。ウィザードまたはサンプル・ギャラリーを再開して、変更を有効にします。