© Copyright International Business Machines Corporation 2006. All rights reserved.
サンプル・ギャラリーからサンプルのポータル・プロジェクトをインポートするか、 または「新規ポータル・プロジェクト」ウィザードを使用してポータル・プロジェクトを作成すると、 「問題」ビューにリンク切れに関する警告メッセージが表示されます。
Rational® のこのバージョンでは、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 セッション Bean
- パレット・ビュー
- Java Bean (メソッド呼び出し)
- Web サービス
- EJB セッション Bean
- 「挿入」->「データ」(Page Designer コンテキスト・メニューまたは Windows メニューから)
- Java Bean (メソッド呼び出し)
- Web サービス
- EJB セッション 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");
- 情報をレンダリング・フェーズに受け渡すためにレンダリング・パラメーターを使用すると、 ブラウザーの「戻る」ボタンのサポートおよびブックマークのサポートが向上する追加の利点があります。
ポータル・プロジェクトのインポート時に、「次のワークスペース・ファイルがエディターと矛盾します。エディターをワークスペースの内容で更新しますか。」という質問メッセージ・ボックスが表示される場合があります。「はい」をクリックします。
JSR 168 仕様では、ポートレット・アプリケーション ID は オプションですが、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 サーバーをローカル・マシンにインストールして、 新規ワークスペースを開始しているというものです。この新規ワークスペースでは、Application Server 6.1 サーバー・インスタンスは 自動的に作成および初期化されるため、Portal 6.0 状態の検出が正しく機能しません。 WebSphere Application Server v6.1 サーバーを作成してから、Portal 6.0 サーバーを作成した場合も、このことが発生する場合があります。
解決策は、Rational 製品を同じワークスペースで再始動することです。 WebSphere Application Server 6.1 サーバーが初期化されないかぎり、つまり、サーバーの状態が「停止済み」または「始動済み」ではなくブランクのままの場合、Portal 6.0 サーバー・インスタンスは正しく機能します。
Portal 6.0 に対してマイ・ポータル・プロジェクトを実行またはデプロイした後、ポートレットがページに表示されません。 この問題の影響を最小限にするため、完全なデプロイメントが不要な場合には常に、構成のみのデプロイメントを使用します。
問題が発生した場合、ポートレットをデプロイせずに、ポータル・プロジェクトの構成のみのデプロイメントを実行してください。 通常、これによって、ポータルでポートレットが再度正しくレンダリングされます。
ビジネス・プロセス・メッセージを新規作成し、WSDL ファイルが文書リテラル・スタイルである場合、入出力メッセージの名前がウィザードの 2 ページ目で表示されないことがあります。ただし、メッセージを選択すると、ウィザード右側のメッセージの詳細を表示することができます。メッセージ名はウィザードに表示されませんが、生成済みコードは正しいものです。
ソースまたはターゲット・ポートレットを作成するために連携ウィザードを使用しており、JSR 168 ポートレット・プロジェクトに複数のポートレットのタイプ (例えば、基本ポートレットと Struts ポートレットが 1 つずつ) が含まれる場合、ウィザードのデフォルト・アクション・パラメーターが正しくないことがあります。
基本ポートレットおよび 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. マイ・タスク・ポートレットで、「構成」ポートレット・ボタンをクリックします。
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 プロジェクトがすでに生成されていることを前提とします。
- 新規に生成された wps 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 に設定されている場合、ポートレット Web モジュールに含まれるコピーではなく、WebSphere Portal 6.0 の jsf-ibm.jar が使用されるためです。
jsf-ibm.jar のコンポーネント (URI http://www.ibm.com/jsf/html_extended に対応) のみ影響を受けます。 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 で構成される場合
WAR を使用してポートレットが WebSphere Portal に直接インストールされている場合、WebSphere Portal 管理ページまたは xmlAccess コマンドを使用して、クラス・ローダー・モードが 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)」を選択してオンにします。ウィザードまたはサンプル・ギャラリーを再始動して、変更を有効にします。