© Copyright International Business Machines Corporation 2006. All rights reserved.
「サーバーにコピーされる最小化アプリケーション・ファイル」オプションは、WebSphere® Application Server 6.0.2.5 以降でサポートされています。 WebSphere Application Server V6.0 サーバー・エディターには、このオプションのチェック・ボックスがあります。このオプションは、バージョン 6.0.2.5 より前のサーバー用に選択された場合には無視されます。
エンタープライズ JavaBean (EJB) モジュールが単一の WebSphere Application Server 上で実行されている複数の EAR プロジェクトによって共用されているときに、そのうちの 1 つの EAR プロジェクトをサーバーから除去する場合、他の EAR プロジェクトが EJB プロジェクト内の EJB Bean などのリソースにアクセスするには、その前にそれらの EAR プロジェクトを再始動する必要があります。
このアクションをとらないと、以下に示されているようなエラー・メッセージが表示されることがあります。 このようなエラーが発生するのは、EAR の除去時に EJB プロジェクト内の Java Naming and Directory Interface (JNDI) 名がサーバーから除去されることが原因です。
以下は、エラー・メッセージの例です。
00000028 SystemOut O javax.naming.NameNotFoundException: コンテキスト: myCell/nodes/myNode/servers/server1、名前: ejb/ejbs/Session20Home: 名前 Session20Home 内の最初のコンポーネントが見つかりません。 [ルート例外は、org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0 です。]
場所は次のとおりです。
com.ibm.ws.naming.jndicos.CNContextImpl.processNotFoundException(CNContextImpl.java:4730)
com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1907)
com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1862)
com.ibm.ws.naming.jndicos.CNContextImpl.lookupExt(CNContextImpl.java:1552)
com.ibm.ws.naming.jndicos.CNContextImpl.lookup(CNContextImpl.java:1354)
com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:172)
javax.naming.InitialContext.lookup(InitialContext.java:363)
com.ibm.ivj.ejb.runtime.AbstractAccessBean.lookupAndCacheHome(AbstractAccessBean.java:224)
com.ibm.ivj.ejb.runtime.AbstractAccessBean.getGlobalHome(AbstractAccessBean.java:216)
com.ibm.ivj.ejb.runtime.AbstractAccessBean.getHome(AbstractAccessBean.java:249)
ejbs.Session20AccessBean.ejbHome(Session20AccessBean.java:50)
ejbs.Session20AccessBean.instantiateEJB(Session20AccessBean.java:80)
ejbs.Session20AccessBean.foo(Session20AccessBean.java:91)
Eclipse ランタイム環境と WebSphere ランタイム環境の間のさまざまな振る舞いおよび相互作用のために、「アプリケーション・クライアントの起動構成 (Application Client Launch Configurations)」ダイアログ・ボックスを通じてマルチスレッド WebSphere アプリケーション・クライアントを実行する場合には、幾つかの追加手順が必要となります。「アプリケーション・クライアントの起動構成 (Application Client Launch Configurations)」ダイアログ・ボックスは、製品のツールバーで「実行」>「実行...」を選択した場合に、J2EE パースペクティブから使用できます。 クライアントが複数のスレッドを使用する場合、または Swing などの追加のスレッドを使用する可能性があるフレームワークを使用する場合は、以下の追加手順も実行する必要があります。
- 「アプリケーション・クライアントの起動構成 (Application Client Launch Configurations)」ダイアログ・ボックスで、「引数」タブを選択します。 「VM 引数」テキスト・ボックスで、以下のパラメーターを指定します。
-Dosgi.noShutdown=true- クライアント・アプリケーションが System.exit() を呼び出すことを確認します。
これを指定しないと、クラス・ロードに関連する問題、またはアプリケーションの実行完了後に終了しない Java™ 仮想マシン (JVM) に関連する問題が発生する場合があります。
以下の構成を持つプロジェクト (例えば、アプリケーション・クライアント・プロジェクト) があるとします。
- Java 用のプロジェクト・ファセットがバージョン 1.4 に設定されている
- このプロジェクトのターゲット・サーバー・ランタイムのサーバー構成内で、ホット・メソッド置換オプションが使用可能に設定されている
「デバッグ」ビューの「再開」ボタンが正常に機能しない可能性があります。 例えば、サーバー上でアプリケーションをデバッグ・モードで実行した際、実行時にソースの変更を試行してから、「再開」ボタンを使用してアプリケーションのデバッグを続行した場合などです。 ホット・メソッド置換によるソース・コードへの変更が適用されていない可能性があります。
実行時の変更を有効にするには、「再開」ボタンを 2 回クリックしてみてください。
注: この問題は、Java のプロジェクト・ファセットをバージョン 5.0 に設定した場合には発生しません。
「共用 WebSphere サーバーの管理」ダイアログ・ボックスの「除去」ボタンが正しく機能しません。
ヒント: 「共用 WebSphere サーバーの管理」ダイアログ・ボックスを開くには、次のようにします。
- ツールバーで、「ウィンドウ」>「設定」を選択します。「設定」ダイアログがオープンします。
- 左側のペインで、「サーバー」>「WebSphere」>「WebSphere v51」を選択します。
- 右のペインで、「共用 WebSphere サーバー」フィールドの隣の「管理」ボタンをクリックします。「共用 WebSphere サーバーの管理」ダイアログ・ボックスが開きます。
「除去」ボタンを使用すると、サーバーは除去済みであると示されます。しかし、このダイアログ・ボックスを終了してから、もう一度開いて、リモート・サーバー情報を最新表示すると、すでに除去したはずのサーバーがダイアログ・ボックス内に残っています。
この問題に対処するには、次の手順に従って、共用サーバー項目を手動で除去します。
- 以下のディレクトリー内に置かれている id.txt ファイルを開きます。
<directory>/plugins/com.ibm.etools.websphere.tools*/properties
ここで、<directory> は、Agent Controller のインストール・ディレクトリーです。- 除去しようとしている共用サーバーを参照している項目を削除します。
- サーバーの作成中に該当共用サーバー用に指定した WebSphere デプロイメント・ディレクトリーおよびそのすべてのサブディレクトリーを除去します。 WebSphere デプロイメント・ディレクトリーの下の除去対象のサブディレクトリーの例には、config、installedApps、temp、および他のすべてのディレクトリーと、そのディレクトリーの下に置かれているファイルがあります。
- 「共用 WebSphere サーバーの管理」ダイアログ・ボックスで、ホスト名を指定し、「更新」ボタンをクリックして、共用サーバーが正常に除去されたことを確認します。
同じ WebSphere Application Server v6.x プロファイル内に、IBM HTTP Server などの追加のサーバーがインストールされている場合、「新規サーバー」ウィザードの「WebSphere サーバーの設定」ページに、正しいリモート・メソッド呼び出し (RMI) または SOAP のポート番号が見つからないことがあります。 また、管理コンソールのポート番号が取得されない場合もあります。
「新規サーバー」ウィザードがサーバー用に定義された実際のポート番号を見つけられない場合、このウィザードのデフォルトの動作では、ポート・フィールドにデフォルトのポート番号 (RMI の場合は 2809、SOAP の場合は 8880) が事前に取り込まれます。
適切でないポート番号が定義されている場合は、以下の問題が発生する可能性があります。
- サーバーを始動または停止できないなど、新規サーバーに接続できない。
- 新規サーバーから管理コンソールを開けない。その結果、管理コンソール・ポートが定義されていないというエラーが表示される場合があります。
- このサーバー上でアプリケーションを実行できない。たとえば、「サーバーで実行」コマンドが機能しなくなります。
回避方法:
- サーバー構成ファイルを参照して、構成済みプロファイルのポートの値を判別します。ポートの値は、以下のディレクトリー内の serverindex.xml ファイルに格納されています。
<directory>¥profiles¥<profileName>¥config¥cells¥<cellName>¥nodes¥<nodeName>。ここで、<directory> は WebSphere Application Server のインストール・ディレクトリーです。
serverindex.xml ファイルを使用して以下の表を完成させ、サーバー用に定義されている実際のポート番号を判別してください。
ポート名 ポートの説明 デフォルトのポート番号 割り当てるポート番号 SOAP_CONNECTOR_ADDRESS SOAP 8880 BOOTSTRAP_ADDRESS RMI 2809 WC_adminhost 管理コンソール 9060 WC_defaulthost HTTP トランスポート 9080 - サーバーに接続するには、サーバーの作成時に正しい RMI または SOAP ポート番号を指定します。
- 管理コンソールを開始するには、外部 Web ブラウザーを使用して、次のように正しい管理コンソール・ポートへの URL をアドレス・フィールドに入力します。
http://<machine_name>:<WC_adminhost>/IBM/console
たとえば、http://localhost:9060/IBM/console と入力します。- サーバー上でアプリケーションを実行するには、「サーバーで実行」コマンドを発行してください。Web ブラウザーが開いたら、サーバー用に定義した HTTP トランスポートのポート番号を使用して、URL を訂正してください。
http://<machine_name>:<WC_defaulthost>/<ContextRoot>/<application_start_page>
たとえば、 http://localhost:9080/MyApplication/index.jsp と入力します。
注: 「サーバー」ビューで自動的に定義されたサーバーは、実際のサーバーの正しいポート番号を参照していないことがあります。この場合は、上記と同じ回避方法を使用してください。
プロファイル管理ツールは、各ランタイム環境用にプロファイルを作成する WebSphere Application Server のツールです。ワークベンチを使用して、WebSphere Application Server のプロファイル管理ツールを開始することができます。 ただし、プロファイル管理ツールは 64 ビット・プロセッサーでは動作しませんので、代わりに WebSphere Application Server によって提供されている manageprofiles コマンド行ツールを使用してください。
Windows オペレーティング・システムでリモート・メソッド呼び出し (RMI) ポートを使用して WebSphere Application Server v6.x に接続している場合、ネットワーク接続が失われた後、サーバーへの接続の確立時に長い遅延が生じることがあります。これが起きる可能性があるのは、サーバーがローカルであって、ネットワーク接続が単に一時的に失われただけの場合です。このことは、ワイヤレス・ネットワーク環境ではよくあることです。
サーバーが始動済みであることが分かっており、「サーバー」ビュー内での状況として「停止済み」または「始動中」が表示されている場合は、サーバー接続を RMI から SOAP に切り替えることによって、サーバーへの接続を確立できるかどうかを調べてみてください。 サーバーの状況は、「始動済み」に変わります。ワイヤレス・ネットワーク環境で、サーバーへの接続を確立するときに利用できるオプションをいくつか以下に示します。
- 簡単かつ安全なオプションは、SOAP ポートを使用するように接続を切り替えることです。RMI 接続と比較して SOAP 接続のほうが、ネットワーク接続が失われた後により速やかにリカバリーする機能を備えています。
- RMI 接続を使用する必要がある場合、Windows オペレーティング・システム上のドメイン・ネーム・システム (DNS) キャッシュに関連するデフォルト設定の変更を行ってみることができます。詳しくは、以下の Microsoft のサポート記事を参照してください。
http://support.microsoft.com/kb/318803
Windows オペレーティング・システムには、解決済みのホスト名を保守する DNS キャッシュが組み込まれています。これは、DNS ルックアップ実行時のターンアラウンドをさらに高速化することができます。ただし、これには欠点があります。つまり、DNS ルックアップが失敗した場合です。 Windows オペレーティング・システムは、デフォルト期間の 300 秒の間、失敗した値をキャッシュに入れます。したがって、DNS サーバーは、ルックアップを直後に解決できても、キャッシュ期間が満了するまで実際にはルックアップを試みません。 その結果、デフォルト設定を持つ DNS ルックアップが失敗した場合、そのルックアップが実際に再試行されるまでに 5 分も要する可能性があります。キャッシュ時間を 0 秒に設定すれば、失敗した DNS ルックアップ照会は Windows オペレーティング・システムでは決してキャッシュに入れられなくなるので、DNS が使用可能になればすぐに再接続が試みられます。
Windows オペレーティング・システムでルックアップが失敗した場合に備えて、DNS キャッシュを無効にする例を以下に示してあります。
以下のレジストリー・キーを使用します。 HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Services¥Dnscache¥Parameters
次のようなレジストリー値の 1 つを追加します。
- Windows XP/2003 の場合:
"MaxNegativeCacheTtl"=dword:00000000- Windows 2000 の場合:
"NegativeCacheTime"=dword:00000000
アプリケーションの再公開、アプリケーションの再始動、またはアプリケーションのアンインストールおよび再インストールは、アプリケーション・デプロイメント記述子エディターの「デプロイメント」ページで定義された、さまざまなリソースの変更をサーバーに適用するには、十分なアクションではありません。エディターの「デプロイメント」ページでのデータ・ソースのデータベース名への変更は、サーバーが取得できない変更であることが分かっており、他にもサーバーが取得できない変更は幾つか存在する可能性があります。
回避方法として、以下の手順を完了して変更をサーバーに適用してください。
- サーバーを停止します。
- 「サーバー」ビューでサーバーを右クリックし、「停止」を選択します。
- 「サーバー」ビューでサーバーの状況が「停止済み」と表示されるまで待ってから、次の手順を続行します。
- ワークベンチを開始します。
注: サーバーの始動に失敗した場合は、オペレーティング・システムの機能を使用して、そのサーバーが実行されている java プロセスを停止する必要があります。 あるいは、ワークベンチを再始動してから、サーバーの始動を再試行することもできます。- サーバーを始動します。
- 「サーバー」ビューで、サーバーを右クリックし、「始動」を選択します。
- 「サーバー」ビューで、再公開が完了してサーバーおよびアプリケーションの状況に「始動済み 」と表示されるまで待ってから、次の手順に進みます。
- 例えば、「サーバーで実行」コマンドを使用して、サーバー上でアプリケーションを実行します。 その結果、サーバーはアプリケーション・デプロイメント記述子エディターによる変更を取得できるようになります。
Web プロジェクトの Web ライブラリーにユーティリティー JAR ファイルを追加し、コードでその JAR ファイル内のクラスを参照する場合、サーバー上でアプリケーションの実行を試行すると java.lang.NoClassDefFoundError エラーが発生する場合があります。
この問題を回避するには、以下の手順に従って、ユーティリティー JAR ファイルを EAR モジュールに追加してから、その JAR ファイルを Web プロジェクトの J2EE モジュール依存関係に追加します。
- ユーティリティー JAR ファイルを EAR モジュールに追加します。 詳しくは、製品のヘルプの『プロジェクト・ユーティリティー JAR ファイルの追加』トピックを参照してください。
- Web プロジェクトを右クリックして、「プロパティー」を選択します。 「プロパティー」ダイアログ・ボックスが開きます。
- 「J2EE モジュール依存関係 (J2EE Modules Dependencies)」を選択します。
- 「JAR/モジュール」列の下の「J2EE モジュール」タブで、ユーティリティー JAR ファイルの横のチェック・ボックスを選択します。
WebSphere Application Server V6.1 をセキュアな SOAP 接続上で実行しているときに、別のセキュアな SOAP 接続を WebSphere Application Server V6.0 に接続しようとすると、失敗します。順序がこの逆の場合も、同じ問題が発生します。つまり、WebSphere Application Server V6.0 をセキュアな SOAP 接続上で実行していると、WebSphere Application Server V6.1 へのセキュアな SOAP 接続は失敗します。ただし、「サーバー」ビューでサーバーを定義していて、その状況がブランクになっていれば、この問題は発生しません。
この問題を回避するには、サーバーへの接続に、SOAP 接続ではなくセキュアなリモート・メソッド呼び出し (RMI) 接続を使用するか、または非セキュアな SOAP 接続を使用します。
リモート・サーバーを停止した場合、「終了」ボタンをクリックしたときに、「新規サーバー」ウィザードが完了するまでに要する時間が長くなることがあります。 回避方法は、「新規サーバー」ウィザードの「終了」ボタンをクリックする前に、リモート・サーバーを始動することです。
.war 拡張子を持つファイルが EAR プロジェクトの EarContent フォルダー内に配置され、application.xml で Web モジュールとして定義されていない場合、エンタープライズ・アプリケーションはサーバーでの公開に失敗し、以下のようなエラー・メッセージが出されます。
org.eclipse.jst.j2ee.commonarchivecore.internal.exception.OpenFailureException: IWAE0034E "D:¥myworkspace¥PublishEAR¥EarContent" 内のネストされたアーカイブ "abc.war" を開くことができませんでした。このエラーの原因は、ワークベンチがそのファイルを Web モジュールとして正しく処理できなかったことにあります。以下の回避方法のいずれかを選択してください。
- ファイルが Web モジュールである場合は、そのファイルをモジュールとしてエンタープライズ・アプリケーションに追加します。 詳しくは、製品ヘルプの『Adding modules to an enterprise application』を参照してください。
- ファイルが Web モジュールでない場合、公開での問題に対して推奨される対策としては、ファイル拡張子を、たとえば .jar のように、.war 以外の別の拡張子に変更します。
リモート WebSphere Application Server V5.1 またはリモート WebSphere Application Server V5.1 Express Edition では、デプロイメント・ディレクトリーおよび公開ディレクトリーをサーバー・エディターで変更してからそのアプリケーションを再公開した場合、アプリケーションは引き続き前の宛先への公開を続けます。その結果、公開ディレクトリーおよびデプロイメント・ディレクトリーの変更内容は適用されません。 この問題が起きるのは、ローカル・コピーまたは FTP 方式の使用時です。
この問題を回避するには、ワークベンチを再始動します。これにより、公開ディレクトリーおよびデプロイメント・ディレクトリーの構成変更が有効化されるはずです。
プロジェクトの保管に対するさらに柔軟なアプローチをサポートするために、アプリケーションの公開技法が変更されました。 アプリケーションは、サーバーに公開される前にコピーされるようになりました。 アプリケーションが大規模な場合 (例えば、100 メガバイトを超えるような場合)、以前のバージョンでかかった時間に加えて、この公開コマンド用に使用されるコピー操作にかかる時間が追加されます。
現在のところ、回避方法はありません。 IBM では、この新しいコピー操作をほとんどの場合に実行する必要がなくなるような更新への取り組みを行っています。
保護された WebSphere Application Server v6.1 が始動済みの場合に、サーバー・エディターでサーバーの接続タイプをリモート・メソッド呼び出し (RMI) または SOAP に変更すると、そのサーバー・エディターで変更内容を保管した後で、以下の公開の失敗エラー・メッセージが表示される可能性があります。
サーバーが始動していないため、公開が実行されません。サーバーを開始してから、公開操作を行ってください。
このエラーは、無視しても構いません。 オプションで、「サーバー」ビューのサーバーの状況が「始動済み」になったら、公開コマンドを完了することができます (「サーバー」ビューで、サーバーを右クリックし、「公開」を選択します)。
「テーブルおよびデータ・ソース・クリエーター」ウィザードを使用してデータ・ソースを生成しようとした場合、「テーブルおよびデータ・ソース作成の結果」ダイアログ・ボックスの「詳細」セクションに TargetInvocationException エラーが示されることがあります。
TargetInvocationException エラーは、同じ Java Naming and Directory Interface (JNDI) 名で定義されたデータ・ソースを含むプロジェクト交換をインポートした場合に発生する可能性があります。
TargetInvocationException エラーに対処するには、同一の JNDI 名の付いたデータ・ソースがすでにワークベンチに定義されているかどうかを確認します。 定義されている場合は、アプリケーション・デプロイメント記述子エディターの「デプロイメント」ページからそのデータ・ソースを削除し、別の JNDI 名を使用してデータ・ソースを再作成します。 JNDI 名は、エンタープライズ Bean をデータ・ソースにバインドする際に使用される命名およびルックアップ・サービスであるため、固有のものである必要があります。
「サーバー」ビューからサーバーを停止したときに、サーバーが完全に停止しない場合があります。「サーバー」ビューには「停止済み」と表示されますが、サーバー・プロセスは応答不能状態にあることがあります。 これは通常、アプリケーションまたはワークベンチなどの成果物が、サーバー上のクラスへの参照を保持し続けている場合に発生します。 以下はシナリオ例です。
- アプリケーションがエンドレス・ループに入っているか、またはアプリケーションがサーバー上の幾つかのクラスへの参照を保持している場合
- アプリケーションが、自身の接続をクリーンアップしないで、Cloudscape または Derby データベース接続を確立する場合
- データベースへの接続を切断しないまま、データ・ツールの「新規接続」ウィザード内の「接続のテスト」ボタンを使用して、Cloudscape または Derby データベースへの接続を開いた場合
制限事項: Cloudscape または Derby の構成上の制限のため、単一の Cloudscape または Derby データベースへの複数の接続はサポートされていません。 データベース・エクスプローラーからデータベースへのデータベース接続を保守する場合、サーバーがデータ・ソースを通じて別の Cloudscape 接続または Derby 接続の作成を試行すると、2 番目の接続は失敗します。そのため、サーバーが Cloudscape または Derby データベースへの接続を確立するためには、まずデータベース・エクスプローラーから接続を閉じる必要があります。
この問題を回避するには、オペレーティング・システムの機能を使用して、そのサーバーが実行されている java プロセスを停止する必要があります。あるいは、ワークベンチを再始動し、参照を強制的に解放することもできます。 3 番目に解説した最後のシナリオ例では、データベース・エクスプローラー・ビューを使用して、Cloudscape または Derby データベース接続に接続してから切断することができます。
サーバーにリソース (例えば、エンタープライズ Bean) を公開する場合に、Universal Test Client (UTC) を使用して EJB のテストを行うと、JAR ファイルがロックされて、更新できなくなる可能性があります。そのため、EJB のテスト中にツールで行われた変更が反映されなくなります。 UTC が EJB JAR ファイルをロードすると、その JAR ファイルは、アプリケーションが除去されて再度追加されるか、サーバーが再始動されるまで、ロックされたままとなります。
この問題を回避するには、アプリケーションのリソースがワークスペースの外で実行され、サーバー上では実行されない開発環境で UTC を使用することです。これは、「新規サーバー」ウィザードを使用して構成するか、サーバー・エディターを使用して「公開」オプションの「サーバーをワークスペース内のリソースで実行する」を選択することで、後から変更することもできます。 これにより、EJB JAR ファイル全体の完全な置換を必要とせずに、EJB プロジェクト内の個々のファイルを更新することができます。
アプリケーションのテストが完了すると、「サーバーをサーバー上のリソースで実行」公開オプションを使用して、サーバーに公開できるようになります。