トラブルシューティング

一般的な問題やそのソリューションについて、下記の表を参考にしてください。

その他のトラブルシューティング・リソース

Rational® ツールの README ファイルを参照してください。 「スタート」メニュー (Windows®) から、または Rational Software Development Platform のインストール・ランチパッドから使用可能です。

問題の解決

問題 ソリューション
WebSphere® Portal v5.x テスト環境を開始できない
  • WebSphere Portal v5.x テスト環境をインストール済みであることを確認してください。 インストール・ログを調べて、インストールが成功したかどうかを確認してください。WebSphere Portal v5.0 テスト環境のインストール・ログは、workbench_installdir¥runtimes¥portal_v50¥log¥wpsinstalllog.txt です。
  • サーバー構成を変更してください。このソリューションが適用されるのは、WebSphere Portal v5.x テスト環境がデバッグ・モードで開始できない場合だけです。サーバー構成で、サーバー・ページの「デバッグ・モードのホット・メソッド置換を使用可能にする」チェック・ボックスが選択されていることを確認してください。これを行う手順は、次のとおりです。
    1. 「サーバー」ビューで、サーバー構成を開くために、デバッグ・モードで開始できない WebSphere Portal v5.x テスト環境をダブルクリックする。
    2. 概要」ページを選択する。
    3. デバッグ・モードのホット・メソッド置換を使用可能にする」チェック・ボックスを選択する。
    4. Ctrl+S を押して、更新されたサーバー構成を保管する。
  • Linux® のみ: WebSphere Portal データベースのアクセス許可を変更してください。WebSphere Portal の制限事項があるので、WebSphere Portal v5.x テスト環境が使用できるのは、一つのユーザーが使用する場合だけです。WebSphere Portal データベースに対する読み取り、書き込み、および実行の許可をオンにすると、他のユーザーがサーバーを使用することを許可できます。 アクセス許可を変更するには、次のコマンドを入力します。
    1. cd /opt/PortalUTE/PortalServer/cloudscape/
    2. chmod -R 777 wps50
    別の方法として、WebSphere Portal v5.x テスト環境をいったんアンインストールしてから、再インストールすると、サーバーを使用できるユーザーを変更できます。
  • Windows のみ: Windows ユーザーがアドミニストレーターであることを確認してください。ログインしていない場合は、アドミニストレーターとして Windows にログインし、WebSphere Portal v5.x テスト環境を実行してください。
  • Struts ポートレットを実行またはデバッグするには、ポートレットに静的 (非 JSP) または XML コンテンツがある場合、トランスコーディングを使用可能にする必要があります (トランスコーディングの使用可能化を参照)。
  • 他の Java™ または EJB プロジェクトを参照するポートレット・プロジェクトを実行またはデバッグする場合は、他のプロジェクトの参照 を参照してください。
  • アプリケーション・ライブラリー・ファイルを使用するポートレット・プロジェクトを実行またはデバッグする場合は、ポートレットのテスト用のローカル・サーバーの定義の共用ライブラリーについてのセクションを参照してください。
  • WebSphere Portal のログを調べて、問題を判別してください。ログ・ファイルを参照するか、ポートレットのテスト用のローカル・サーバーの定義で説明されているようにコンソール・ログを使用可能にしてください。
WebSphere Portal v5.x テスト環境用のサーバーを作成できない。
  • 使用したい WebSphere Portal v5.x テスト環境がインストールされていることを確認してください。WebSphere Portal v5.x テスト環境サーバーを作成できるのは、テスト環境がインストールされている場合だけです。
  • (WebSphere Portal v5.1 のみ) WebSphere Portal 5.1 テスト環境の構成で説明されているように設定を構成済みであることを確認してください。
WebSphere Portal 5.1.0.0 テスト環境でテストすると、次のエラーが発生する。 com.ibm.websphere.wmm.exception.InvalidMemberDNException: The syntax of the member DN <admin_user_id> is invalid.Check if the special characters are escaped. ターゲット・サーバーに対して定義されている管理者ユーザー ID は、 Portal テスト環境のインストールに使用するユーザー ID と同じでなければなりません。
インポート、エクスポート、またはデプロイされたポータルに対して、JSP または Java コンパイル・エラーが発生する。 一部のクラスに外部 JAR ファイルを利用する JSP ファイルまたは Java クラスは、次のいずれかの状態が発生する場合、コンパイルできないことがあります。
  • JSP ファイルまたは Java クラスが、リモート・ポータル・サーバーからインポートされ、リモート・サーバーの WebSphere_install_directory/lib または Portal_server_install_directory/shared/app ディレクトリーに置かれている外部 JAR ファイルを使用する。
  • JSP ファイルまたは Java クラスが、JAR ファイルにアクセスできる Rational ツール・プロジェクトからエクスポートされ、JAR ファイルにアクセスできないリモート・ポータル・サーバーにインストールされている。
  • JSP ファイルまたは Java クラスが、JAR ファイルにアクセスできる Rational ツール・プロジェクトからデプロイされ、ターゲット・ポータル・サーバーが、JAR ファイルにアクセスできない。

これが発生するのは、インポート、エクスポート、およびデプロイ操作が、参照される JAR ファイルに影響を与えないからです。

この問題を解決するには、ポータル・プロジェクトが外部 JAR ファイルを使用する場合、その JAR ファイルをサーバーから利用可能できるようにする必要があります。
  • JAR ファイルをポータル・プロジェクトから使用できるようにするには、JAR ファイルを開発マシンにコピーし、ポータル・プロジェクトの Java のビルド・パスに追加してください。 Java のビルド・パスを設定するには、次の手順を実行します。
    1. 「プロジェクト・エクスプローラー」ビューで、プロジェクトを強調表示し、「プロパティー」を選択する。
    2. 左のペインで、「Java のビルド・パス」を選択する。
    3. 右のペインで、「ライブラリー」タブを選択する。
    4. 参照された JAR を追加する。
    5. 「OK」をクリックして構成を保管する。
  • JAR ファイルを WebSphere Portal テスト環境から使用できるようにするには、JAR ファイルを開発マシンにコピーし、テスト環境サーバーの workbench_install_directory/runtimes/portal_v5X/shared/app ディレクトリーに追加してください。
  • JAR ファイルをリモート・ポータル・サーバーから使用できるようにするには、ポータル・プロジェクトをエクスポートまた はデプロイした後、必要な JAR ファイルをリモート・ポータル・サーバー・システムに手動でコピーしてください。
WebSphere Portal v5.x テスト環境の java.lang.NoClassDefFoundError ローカル・デバッグを使用してポートレット・アプリケーションをテストまたはデバッグする際に、そのポートレット・アプリケーションがライブラリー・ファイルを使用するか、他のプロジェクトを参照する必要がある場合、それらをサーバーから使用できるようにする必要があります。 ポートレットのテスト用のローカル・サーバーの定義または他のプロジェクトの参照で共用ライブラリーに関するセクションを参照してください。
WebSphere Portal v5.0 テスト環境 サーバーでのポートレットの実行中またはデバッグ中に、トランスコーディング機能が正常に機能しない。 トランスコーディング機能は、デフォルトで、WebSphere Portal v5.0 テスト環境で使用不可になっています。 これを使用可能にする必要があります。トランスコーディングの使用可能化を参照してください。
WebSphere Portal v5.0 テスト環境を使用して WML デバイス・エミュレーターを起動できない。 WebSphere Portal v5.0 テスト環境を使用して WML デバイス・エミュレーターでポートレットを実行またはデバッグするには、トランスコーディングを使用可能にする必要があります。トランスコーディングの使用可能化を参照してください。また、Web ブラウザーとデバイス・エミュレーターの定義の説明を使用してデバイス・エミュレーター・プログラムを定義することも必要です。
WebSphere Portal v5.x テスト環境で、パーソナライズされたポートレット・プロジェクトを実行できない。 パーソナライズされたポートレット・プロジェクトを実行またはデバッグするには、リモート・サーバーで実行されている WebSphere Portal サーバー接続および WebSphere Portal を使用する必要があります。
EJB 断片サポートによって使用されるユーティリティー *.jar ファイルが含まれている Faces ポートレットが、リモートの WebSphere Portal Server で実行時に失敗する。 これは、これらのポートレットを新規ポータル・プロジェクトの一部としてポータル・サーバーにデプロイする際に発生します。

詳しくは、J2EE モジュールを参照するポートレットのテストおよびデプロイを参照してください。

ポータル・プロジェクトで使用しているポートレットで「サーバーで実行」を実行すると、 「サーバーの選択」ダイアログで予期しない EAR ファイルが生成される。 ポートレット・プロジェクトを選択せずに、 ポートレットの EAR プロジェクトを選択し、右クリックして「サーバーで実行」機能を実行します。
ポートレット・プロジェクトの EAR ファイルを検索する手順は、次のとおりです。
  1. 「プロジェクト・エクスプローラー」で、エンタープライズ・アプリケーション・ノードを展開する。
  2. ポートレット・プロジェクトの EAR ノードを右クリックする。メニューから、「実行」 > 「サーバーで実行」を選択する。
Rational Software Development Platform の始動時にワークベンチを復元できませんでしたというエラーが表示される。 Rational ツールを再始動し、ワークスペースとして新規ディレクトリーを指定してください。 事前に「このワークスペースをデフォルトで使用し、このダイアログ・ボックスを再び表示しない」を選択しており、 ワークスペース・ディレクトリーを指定するダイアログが表示されない場合は、-data パラメーターを指定してワークベンチを始動してください。 コマンド行から次のように入力します。


Windows の場合

cd workbench_installdir
rationalsdp.exe -data workspace_directory


Linux の場合

cd workbench_installdir
rationalsdp.sh -data workspace_directory

ここで、workbench_installdir は、Rational Software Development Platform をインストールしたディレクトリーであり、workspace_directory は、使用したい新規ワークスペース・ディレクトリーです。

WebSphere Portal 4.2 用に開発されたポートレットが、WebSphere Portal 5.x で正しく機能しない。 このソリューションは、ポートレットが Portal Toolkit 5.0.2 以前で開発された場合にのみ有効です。
これを 修正するには、次のいずれかの手順を実行します。
  • /WEB-INF/tld/portlet.tld ファイルを、 ポートレット・プロジェクトから削除してください。
  • 以下のステップを実行して、ポートレット・プロジェクトの「ポートレット API レベル」を 変更してください。
    1. 「プロジェクト・エクスプローラー」ビューで、ポートレット・プロジェクトを強調表示する。
    2. 右クリックし、「プロパティー」 > 「ポートレット API」を選択する。
    3. ドロップダウン・リストを使用して、「ポートレット API レベル」を 選択する。
    4. 「OK」 を選択して変更を保管します。

WebSphere Portal バージョン 4.2 用に作成された大部分のポートレットは、WebSphere Portal バージョン 5.x で、変更なく実行されます。ポートレット API 4.2.x の一部は、「使用すべきではない」というマークが付いていますが、WebSphere Portal バージョン 5.x で引き続き使用できます。 ただし、portlet.tld ファイルは WebSphere Portal のバージョンによって異なります。 Portal Toolkit 5.0.2 以前では、このファイルはポートレット・プロジェクトに含まれていました。

テスト環境におけるポートレットの実行 (テスト) またはデバッグが失敗した。 「サーバーで実行」または「サーバーでデバッグ」タスクを起動した後、テスト環境は始動中 状態になったが、終了した。 ポートレットには、JSP ファイルまたは Java コードに検証エラーがなく、デプロイメント記述子は正しい。 ワークベンチの「設定」で「自動的にビルド」が選択されていることを確認してください。 値を確認するには、「ウィンドウ」 > 「設定」 > 「ワークベンチ」を選択してください。
リモート・システム上でのポートレットのデプロイメントまたはテストが失敗した。 この失敗は、次のどのタスクでも発生する。
  • 「デプロイ」ウィザードを使用したポートレットのデプロイ
  • サーバー接続サーバーを使用したポートレット・プロジェクトの実行またはデバッグ
  • ポートレット・プロジェクトを使用するポータル・プロジェクトのデプロイ
  • ポートレット・プロジェクトを使用するポータル・プロジェクトの実行またはデバッグ
サーバーが正しく構成されていることを確認してください。ネットワークに関する考慮事項を参照してください。
WebSphere Portal v5.x テスト環境サーバーでプロジェクトの実行またはデバッグを行うと、「コンソール」ビュー内のコンテンツが切り捨てられる。 ワークベンチの「設定」で「コンソール出力の制限」が選択されていないことを確認してください。 値を確認するには、「ウィンドウ」 > 「設定」 > 「実行/デバッグ」 > 「コンソール」の順に選択してください。
複数の JSR 168 ポートレット・プロジェクトが関連付けられている場合、WebSphere Portal v5.1 テスト環境が開始しない。 複数の JSR 168 ポートレット・プロジェクトがサーバーに関連付けられ、ポートレット・デプロイメント記述子の <portlet-app> エレメントの ID 属性がない場合、WebSphere Portal v5.1 テスト環境は開始できません。ID 属性が固有でない場合も、同じ問題が生じることがあります。 この問題を解決するには、ポートレット・デプロイメント記述子 (portlet.xml) を編集し、固有の値を持つ ID 属性を <portlet-app> エレメントに追加してください。 ポートレット・デプロイメント記述子を編集する場合、ソース・ページを使用して変更を加えてください。
WebSphere Portal v5.0 サーバーへの JSR 168 ポートレット・プロジェクトのデプロイメントが、1 回だけしか機能しない。 WebSphere Portal Server の WebSphere Portal 管理ページを使用して、デプロイしたい JSR 168 ポートレットを除去 (アンインストール) し、ポータル・サーバーにフィックス PQ92087 を適用してから、Rational Software Development Platform を使用してポートレットを再度デプロイしてください。
ポートレット WAR ファイルをインポートするときに、WebSphere Portal サーバーがターゲット・サーバー・リストに表示されない。 WAR ファイルの WEB-INF ディレクトリーの Web デプロイメント記述子 (web.xml) の DOCTYPE エントリーを検査してください。正しい構文は次のとおりです:
<!DOCTYPE web-app 
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" 
"http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
ここで、ストリング web-app_2_2.dtd は、WAR ファイルの Web レベルを定義します。 ストリング web-app_2_2.dtd は、Web レベル 2.2 (J2EE 仕様レベル 1.2) の場合であり、ストリング web-app_2_3.dtd は、Web レベル 2.3 (J2EE 仕様レベル 1.3) の場合です。

共通の間違いは、バージョン番号に「_」文字ではなく、 「.」を使用していることです。 たとえば、web-app_2_2.dtd ではなく、web-app_2.2.dtd としています。

WAR ファイルをまだインポートしていない場合は、次のステップを実行して問題を訂正してください。
  1. web.xml ファイルの DOCTYPE エントリーの構文を訂正する。
  2. WAR ファイルを再パッケージする。
  3. WAR ファイルをインポートする。
WAR ファイルをすでにインポート済みの場合は、次のステップを実行して問題を訂正してください。
  1. 次のステップを実行して、Web デプロイメント記述子の DOCTYPE エントリーを修正する。
    1. 「プロジェクト・エクスプローラー」ビューで、ポートレット・プロジェクトの Web デプロイメント記述子 をダブルクリックする。 Web デプロイメント記述子エディターが開きます。
    2. 「ソース」タブで、DOCTYPE エントリーの構文を訂正する。
    3. Ctrl + s をクリックして、変更を保管する。
  2. 次のステップを実行して、ポートレット・プロジェクトおよび EAR プロジェクトの 「ターゲット・サーバー」を変更する。
    1. 「プロジェクト・エクスプローラー」ビューで、ポートレット・プロジェクトを強調表示する。 右クリックし、「プロパティー」を選択する。「プロパティー」ダイアログ・ボックスが表示されます。
    2. 左のペインで、「サーバー」を強調表示する。
    3. 右のパネルで、ターゲットの「ターゲット・ランタイム」を WebSphere Portal サーバーに変更する。「OK」をクリックする。
    4. 関連した EAR プロジェクトについて上記のステップを繰り返す。
J2EE 依存関係 (データベース接続、EJB および従属ユーティリティー JAR プロジェクトなど) が含まれているポートレットが、ポートレットまたはポータル・プロジェクトがあるリモート・ポータル・サーバーにデプロイされない。

詳しくは、J2EE モジュールを参照するポートレットのテストおよびデプロイおよび 他のプロジェクトの参照を参照してください。

重複 オブジェクト ID

ポータル・プロジェクトのデプロイまたはエクスポートが 失敗する。エラー・メッセージの一部で、PAGE_INST(OID) で定義された主キー制約の DuplicateKeyException が示されます。

WebSphere Portal v5.1 サーバーからオブジェクトが削除されたとき、そのオブジェクトは削除済みのマークが付けられますが、 即時には除去されません。 その際にオブジェクトがリモート・ポータル・サーバー接続サーバーに エクスポートまたはデプロイされると、重複オブジェクト ID のエラーが発生する 可能性があります。

この問題は、以下のシナリオで発生する可能性があります。
  • シナリオ 1:
    1. ポータル・プロジェクトをインポートする
    2. ポータル・プロジェクトでページを削除する
    3. ポータル・プロジェクトをデプロイまたはエクスポートする
    4. ポータル・プロジェクトで同一の固有名を持つページを作成する
    5. ポータル・プロジェクトをデプロイまたはエクスポートする
  • シナリオ 2:
    1. ポータル・プロジェクトをインポートする
    2. WebSphere Portal サーバーでページを削除する
    3. WebSphere Portal サーバーにポータル・プロジェクトをデプロイまたはエクスポートして戻す
  • シナリオ 3:
    1. ポータル・プロジェクトをインポートする
    2. WebSphere Portal サーバーでページを削除する
    3. 「上書きでプロジェクトを削除」オプションを 選択せずに、ポータル・プロジェクトを再度インポートする
    4. WebSphere Portal サーバーにポータル・プロジェクトをデプロイまたはエクスポートして戻す

この問題を解決するには、オブジェクトを即時に除去するように WebSphere Portal を構成するか、XML 構成インターフェースを使用して個々のクリーンアップ・ タスクを実行します。その方法については、WebSphere Portal 製品資料「Administering」 > 「Delayed cleanup of deleted portal pages」セクションを 参照してください。

ラベルおよびページのキャッシュ

リモート・ サーバー接続サーバーでの WebSphere Portal v5.1 ポータル・プロジェクトの実行中は、ラベルおよびページの構造に対する 変更は即時に表示されません。

WebSphere Portal v5.1 サーバーは、ページの内容を キャッシュに入れます。リモート・サーバーでのポータル・プロジェクトの実行時は、 最大 10 分間、ページの内容に対する変更は表示されません。これは、 キャッシュのデフォルトの存続時間です。

キャッシュの存続時間を 変更するには、リモート・ポータル・サーバーの Portal_installation_directory/shared/app/config/services/CacheManagerService.properties ファイルで cacheinstance.com.ibm.wps.model.content.impl.ResourceCache.lifetime パラメーターの 値を変更します。

この値は、キャッシュが保持される秒数です。 値 0 または -1 は、タイムアウトが ないことを意味します。

ラベルおよびページの構造を 変更した場合に、Web ブラウザーでその変更内容が表示されないときは、Web ブラウザーを 使用して WebSphere Portal から明示的にログアウトして、再度ログインします。 ログイン後、変更内容が表示されます。 Web ブラウザー・ウィンドウを閉じても効果がない可能性があることに注意してください。 ログアウトとログインのステップは、更新されたポータル・プロジェクトが 公開されるたびに、実行する必要があります。

WebSphere Portal v5.0 を使用する一部の構成では、ポータルまたはポートレット・プロジェクトに 加えられた変更内容が、そのプロジェクトをリモート・サーバー接続サーバーで 実行またはデバッグする際に Web ブラウザーに自動的に表示されません。
これを処理するには、2 つの方法があります。
  • Web ブラウザーを使用して WebSphere Portal から明示的にログアウトして、再度ログインする。 ログイン後、変更内容が表示されます。 単に Web ブラウザー・ウィンドウを閉じるだけでは、効果がないことに注意してください。 更新されたポータル・プロジェクトが公開されるたびに、ログアウトして ログインする必要があります。
  • または、外部 Web ブラウザーを使用するように、Rational ツールを構成する。 これを行うには、「ウィンドウ」 > 「設定」を選択する。左側で「インターネット」項目を 展開して、「Web ブラウザー」を選択します。 メイン・セクションで、内部 Web ブラウザーを除く任意の Web ブラウザーを 選択します。次に、各「サーバーで実行」または「サーバーでデバッグ」を行う前に、外部 Web ブラウザーを閉じてから操作を実行する必要があります。
テスト環境またはリモート・サーバーのいずれかでデバッグ時にサーバー接続障害が発生する。

サーバーが間違いなく 正しく構成されている のに、デバッグのためにテスト環境またはリモート・ポータル・サーバーに 接続できない場合は、リモート・マシン上の JVM プロセスへの接続時にタイムアウトになったために、この問題が発生した 可能性があります。これは、リモート・マシンがビジーであるか、またはネットワークが 低速な場合に発生することがあります。

デバッグ用のデフォルトのタイムアウト値 (3) を大きくするには、 「ウィンドウ」 > 「設定」 > 「Java」 > 「デバッグ」を選択して、「デバッガー・タイムアウト」フィールドの値を 10 秒 (10) に上げます。

連携ポートレットが、SuSE Linux Enterprise Server バージョン 9 の組み込みブラウザー (Konqueror) で実行されない。

連携ポートレット・メニューをサポートする Web ブラウザーのリストなどの詳細については、WebSphere Portal Information Center にある「Developing portlets」 > 「Cooperative portlets」 > 「Known issues and restrictions with cooperative portlets」の トピックを参照してください。

代替 Web ブラウザーの 定義方法については、Web ブラウザーとデバイス・エミュレーターの定義を 参照してください。

IBM® ポートレット API ポートレット間のワイヤーを持つポータル・プロジェクトが、WebSphere Portal 5.1.0.0 への デプロイまたはエクスポートに失敗する。

連携ポートレットのワイヤリングのデプロイメントの 前提条件の説明を参照してください。

インポートされた WebSphere Portal サーバーから 削除されたワイヤーが、デプロイメント後にリモート・ポータル・サーバーで 引き続き使用できる。

ワイヤーは、iFix PK00815 で更新されている WebSphere Portal サーバーからのみ除去できます。

ポータル・ サーバーを 5.0.2 から 5.0.2.1、さらに 5.0.2.2 にアップグレードした場合に、 Fixpack 7 または Fixpack 8 が適用された DB2® V7.2 を使用しているときは、ポータル・サーバーからポータル・プロジェクトを インポートする際に、エラー・メッセージ「Character reference "#26" is an invalid XML character」が表示されることがあります。 これは、ポータル・サーバーを 5.0.2 から 5.0.2.1 に更新しているときに 問題が発生し、その結果ポータル・データベースで、XMLAccess では無効な 2 バイト文字が壊れたことが原因です。
この問題を修正するには、サーバーに対して 2 つの XMLAccess スクリプトを手動で実行する必要があります。次の手順に従います。
  1. 次の XMLAccess を使用して、ポータル・サーバーから構成全体を エクスポートする。
    xmlaccess -in Export.xml -user wpsadmin -pwd wpsadmin -out serverconfig.xml -url http://hostname/wps/config
    <wps_home>/doc/xml-samples ディレクトリーで Export.xml が 見つかります。
  2. 前のステップの結果作成される serverconfig.xml ファイルを編集する。 ~ などの ANSI 文字を使用するインスタンス &#26; を検索して、このインスタンスをすべて置き換えます。 複数の文字を使用すると、ポータル・データベースで許容されるストリングの長さを 超える可能性があるため、XMLAccess スクリプトでエラーが発生することがあります。 このファイルを保管する。
  3. XMLAccess を使用して、変更済みの serverconfig.xml ファイルを用いて サーバーを再構成する。
    xmlaccess -in serverconfig.xml -user wpsadmin -pwd wpsadmin -url http://hostname/wps/config
  4. これで、ポータル・サーバーからポータル・プロジェクトをインポートできる。
  5. 必要な場合は、RAD を使用して、破損したストリングの各国語翻訳を 修正する。

(C) Copyright IBM Corporation 2002, 2005. All Rights Reserved.