© 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 よりも前のサーバーに対して選択された場合、このオプションは無視されます。
WebSphere Application Server 上で実行されている複数の EAR プロジェクト間で Enterprise JavaBean (EJB) module が共用されている場合において、EAR プロジェクトの 1 つがサーバーから除去されると、他の EAR プロジェクトは、EJB Bean などのリソースにアクセスする前に、その EJB プロジェクト内で再始動する必要があります。
このアクションを実行しないと、次のようなエラー・メッセージが表示される場合があります。これらのエラーは、EJB プロジェクト内の Java Naming and Directory Interface (JNDI) 名が、EAR が除去される際にサーバーから除去されるからです。
以下にエラー・メッセージのサンプルを示します。
00000028 SystemOut O javax.naming.NameNotFoundException: Context: myCell/nodes/myNode/servers/server1, name: ejb/ejbs/Session20Home: 名前 Session20Home の最初のコンポーネントが見つかりません。[Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
at com.ibm.ws.naming.jndicos.CNContextImpl.processNotFoundException(CNContextImpl.java:4730)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1907)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1862)
at com.ibm.ws.naming.jndicos.CNContextImpl.lookupExt(CNContextImpl.java:1552)
at com.ibm.ws.naming.jndicos.CNContextImpl.lookup(CNContextImpl.java:1354)
at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:172)
at javax.naming.InitialContext.lookup(InitialContext.java:363)
at com.ibm.ivj.ejb.runtime.AbstractAccessBean.lookupAndCacheHome(AbstractAccessBean.java:224)
at com.ibm.ivj.ejb.runtime.AbstractAccessBean.getGlobalHome(AbstractAccessBean.java:216)
at com.ibm.ivj.ejb.runtime.AbstractAccessBean.getHome(AbstractAccessBean.java:249)
at ejbs.Session20AccessBean.ejbHome(Session20AccessBean.java:50)
at ejbs.Session20AccessBean.instantiateEJB(Session20AccessBean.java:80)
at 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 に設定されています
- このプロジェクトのターゲット・サーバーのランタイムには、サーバー構成で使用可能になった hot メソッド置換オプションがあります。
「デバッグ」ビューの「再開」ボタンが正しく機能しないことがあります。例えば、サーバー上のアプリケーションをデバッグ・モードで実行する場合、実行時でのソース変更を試行してから「再開」ボタンを使用して、アプリケーションのデバッグを続けます。hot メソッドによるソース・コードへの置換変更が適用されない場合があります。
「再開」ボタンのクリックを 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 Server の「設定」ページが正しいリモート・メソッド呼び出し (RMI) または SOAP ポート番号に位置していない場合があります。また、管理コンソールのポート番号が取得できない場合があります。
「新規サーバー」ウィザードがサーバーに定義された実際のポート番号を位置指定できない場合、そのデフォルトの振る舞いは、デフォルトのポート番号 (RMI の場合は 2809、SOAP の場合は 8880) で事前にポートを埋めます。
誤ったポート番号が定義されている場合は、次の問題が起こることがあります。
- 新規サーバーに接続できません。例えば、サーバーを開始または停止できません。
- この新規サーバーから管理コンソールを開けません。この結果、管理コンソール・ポート未定義エラーを受け取ることがあります。
- このサーバーでアプリケーションを実行できません。例えば、Run on servers コマンドが機能しません。
回避方法:
- サーバー構成ファイルを参照することにより、構成済みプロファイルのポート番号を判別します。ポートの値は、次のディレクトリーにある 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 と入力します。- サーバー上でアプリケーションを実行するには、Run on server コマンドを発行します。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 ポートを使用することです。ネットワーク接続が切れた後で、SOAP 接続は RMI 接続に比べてより迅速にリカバリーする機能があります。
- RMI 接続を使用しなければならない場合は、Windows オペレーティング・システムのドメイン・ネーム・システム (DNS) のキャッシングに関するデフォルト設定の変更をしてみることができます。詳しくは、次の Microsoft サポート項目を参照してください。
http://support.microsoft.com/kb/318803
Windows オペレーティング・システムには、解決済みホスト名を保持する組み込み DNS キャッシングがあります。これにより、DNS ルックアップを発行する場合に、より早い送受反転が可能です。ただし、これには欠点があります。それは DNS ルックアップが失敗した場合です。Windows オペレーティング・システムは失敗した値を、デフォルト時間で 300 秒間、キャッシュします。つまり、たとえ DNS サーバーがルックアップをその直後に解決できても、キャッシュ時間の期限が切れるまで、実際にルックアップを試行しません。その結果、デフォルト設定で失敗した DNS ルックアップは、ルックアップで真の再試行が試行されるまでに 5 分間かかります。キャッシュ時間を 0 に設定すると強制的に、Windows オペレーティング・システムは失敗した DNS ルックアップ照会を 2 度とキャッシュしなくなり、DNS が使用可能になるとすぐに再接続ができるようになります。
以下は、Windows オペレーティング・システムで、失敗したルックアップの DNS キャッシングを使用不可にする例です。
次のレジストリー・キーで以下を実行します。HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Services¥Dnscache¥Parameters
次のレジストリー値の 1 つを追加します。
- Windows XP/2003 の場合:
"MaxNegativeCacheTtl"=dword:00000000- Windows 2000 の場合:
"NegativeCacheTime"=dword:00000000
アプリケーションのリパブリッシュ、アプリケーションの再始動、またはアプリケーションのアンインストールと再インストールは、アプリケーション・デプロイメント記述子エディターのデプロイメント・ページで定義されたさまざまなリソースの変更をサーバーに適用するために十分なアクションではありません。エディターのデプロイメント・ページでのデータ・ソースのデータベース名への変更は、サーバーがピックアップすることができない既知の変更です。サーバーがピックアップできないその他の変更がいくつかある場合があります。
回避方法としては、次のステップを実行して変更をサーバーに適用します。
- サーバーを停止します。
- 「サーバー」ビューで、サーバーを右クリックして「停止」を選択します。
- 「サーバー」ビューで、サーバーのステータスが「停止済み」を表示するのを待ってから次のステップを続けます。
- ワークベンチを開始します。
注: サーバーが開始に失敗すると、オペレーティング・システムから機能を使用して、サーバーが稼働している Java プロセスを停止する必要があります。または、ワークベンチを再始動してからサーバーの再起動を試行することができます。- サーバーを開始します。
- 「サーバー」ビューで、サーバーを右クリックしてから 「開始」を選択します。
- 「サーバー」ビューで、リパブリッシュが終了し、サーバーおよびアプリケーションのステータスが「始動済み」と表示されるのを待ってから次のステップを続けます。
- サーバーでアプリケーションを実行します。例えば、Run on Server コマンドを使用します。その結果、サーバーはアプリケーション・デプロイメント記述子エディターからの変更をピックアップできるようになります。
ユーティリティー JAR ファイルを Web プロジェクトの Web ライブラリーに追加し、ご使用のコードで JAR ファイル内のクラスを参照する場合に、サーバー上でアプリケーションを実行しようとすると java.lang.NoClassDefFoundError エラーが表示されることがあります。
回避方法は、ユーティリティー JAR ファイルを EAR モジュールに追加してから、次のステップを実行することにより、JAR ファイルを Web プロジェクトの J2EE モジュール依存関係に追加します。
- ユーティリティー JAR ファイルを EAR モジュールに追加します。詳細については、製品ヘルプの『プロジェクト・ユーティリティー JAR ファイルの追加』トピックを参照してください。
- Web プロジェクト上で右クリックし、「プロパティー」を選択します。「プロパティー」ダイアログ・ボックスが開きます。
- J2EE モジュール依存関係」を選択します。
- 「JAR/モジュール」列の下の「J2EE モジュール」タブで、ユーティリティー JAR ファイルの横のチェック・ボックスを選択します。
WebSphere Application Server V6.1 がセキュア SOAP 接続上で実行されている場合、WebSphere Application Server V6.0 への別のセキュア SOAP 接続は失敗します。同じ問題は反対の場合も発生します。例えば、セキュア SOAP 接続上で実行されている WebSphere Application Server V6.0 のために、WebSphere Application Server V6.1 へのセキュア SOAP 接続は失敗します。ただし、サーバーが「サーバー」ビューで定義され、そのステータスがブランクである場合は、この問題は起こりません。
回避方法は、SOAP 接続の代わりに、サーバーへのセキュアなリモート・メソッド呼び出し (RMI) 接続を使用するか、非セキュア SOAP 接続を使用します。
リモート・サーバーが停止すると、「終了」ボタンをクリックした後に「新規サーバー」ウィザードが終了するのに長い時間がかかることがあります。回避方法は、「新規サーバー」ウィザードの「終了」ボタンをクリックする前に、リモート・サーバーを開始します。
EAR プロジェクトの EarContent フォルダーに拡張子 .war が付いたファイルがあり、それが application.xml で Web モジュールとして定義されていないと、エンタープライズ・アプリケーションは次のサンプル・エラー・メッセージを表示してサーバー上でパブリッシュに失敗します。
org.eclipse.jst.j2ee.commonarchivecore.internal.exception.OpenFailureException: IWAE0034E ネストされたアーカイブ「abc.war」を「D:¥myworkspace¥PublishEAR¥EarContent」 で開くことができませんでしたこのエラーの原因は、ワークベンチがファイルを Web モジュールとして正しく処理できないことです。次の回避方法の 1 つを選択します。
- ファイルが Web モジュールである場合、ファイルをモジュールとしてエンタープライズ・アプリケーションに追加してください。詳細については、製品ヘルプの『エンタープライズ・アプリケーションへのモジュールの追加』トピックを参照してください。
- ファイルが Web モジュールではない場合、公開している問題を回避するための提案は、ファイルの拡張子を .war 以外のほかの拡張子、例えば、.jar に変更することです。
リモート WebSphere Application Server V5.1 またはリモート WebSphere Application Server V5.1 Express Edition の場合に、サーバー・エディターのデプロイメント・ディレクトリーとパブリッシュ・ディレクトリーを変更してからアプリケーションをリパブリッシュすると、アプリケーションは前の宛先にパブリッシュを続けます。この結果、パブリッシュ・ディレクトリーおよびデプロイメント・ディレクトリーでの変更は適用されません。この問題は、ローカル・コピーまたは FTP メソッドを使用する場合に起こります。
回避方法は、ワークベンチを再始動します。この結果、パブリッシュ・ディレクトリーおよびデプロイメント・ディレクトリーの構成変更が有効になります。
プロジェクトを保管するより柔軟な方法をサポートするために、アプリケーションをパブリッシュする技法が変わりました。アプリケーションは、サーバーにパブリッシュされる前にコピーされるようになりました。アプリケーションが大きい場合、例えば 100 メガバイトを超える場合は、パブリッシュ・コマンドに使用されるこのコピー操作は、これまで前のバージョンで経験していたのとは対照的に、さらに時間がかかるようになります。
現在、この回避方法はありません。IBM® では、ほとんどの場合にこの新規コピーを実行する必要を廃したアップデートに取り組んでいます。
保護された WebSphere Application Server v6.1 が開始され、サーバー・エディターでサーバー接続タイプをリモート・メソッド呼び出し (RMI) または SOAP のいずれかに変更すると、サーバー・エディターで変更を保管した後で次のパブリッシュ失敗のエラー・メッセージが表示されることがあります。
サーバーが開始されていないので、パブリッシュは実行されません。パブリッシュ操作を実行する前にサーバーを開始してください。
このエラーは無視してかまいません。オプションで、「サーバー」ビューのサーバーのステータスが「始動済み」になってから、publish コマンドを完了することができます (「サーバー」ビューでサーバーを右クリックし、「パブリッシュ」を選択します)。
「テーブルおよびデータ・ソース・クリエーター」ウィザードを使用してデータ・ソースを生成しようとすると、「テーブルおよびデータ・ソース作成結果 (Table and Data Source Creations Results)」ダイアログ・ボックスの「詳細」セクションに TargetInvocationException エラーが表示される場合があります。
TargetInvocationException エラーが起こる原因は、同じ Java Naming and Directory Interface (JNDI) 名を使用して定義されたデータ・ソースを含むプロジェクト交換をインポートする場合です。
TargetInvocationException エラーを回避するには、同じ JNDI 名を持つデータ・ソースがすでにワークベンチで定義されているかどうかを検証します。定義されている場合は、アプリケーション・デプロイメント記述子エディターのデプロイメント・ページからこれを除去してから、別の JNDI 名を使用してデータ・ソースを再作成します。この JNDI 名は固有でなければなりません。これは、エンタープライズ Bean をデータ・ソースにバインドするために使用されるのはネーミングおよびルックアップ・サービスであるためです。
「サーバー」ビューからサーバーを停止する場合、サーバーが完全に停止しない場合があります。「サーバー」ビューでは「停止済み」と表示されますが、サーバー・プロセスが非応答状態であることがあります。これは通常、アプリケーションやワークベンチなどの成果物が、サーバー上でクラスへの参照を保持し続けている場合に起こります。以下にシナリオ例を示します。
- アプリケーションが無限ループになっている、またはアプリケーションが、サーバー上のクラスの一部への参照を保持する
- 接続をクリーンアップしないで Cloudscape または Derby データベース接続を作成するアプリケーション
- データ・ツールの「新規接続」ウィザードの「接続のテスト」ボタンを使用して、データベースからの切断をせずに Cloudscape または Derby データベースへの接続を開きます。
制限: 単一の Cloudscape または Derby データベースへの複数接続は、Cloudscape または Derby 構成の制限のため、サポートされません。Database Explorer からデータベースへの接続を維持し、サーバーがデータ・ソースを介して別の Cloudscape または Derby 接続を作成しようとすると、2 番目の接続は失敗してしまいます。この結果、ユーザーはサーバーが Cloudscape または Derby データベースへの接続を確立する前に、Database Explorer からの接続をクローズする必要があります。
回避方法: オペレーティング・システムの機能を使用して、サーバーが実行されている java プロセスを停止してください。または、ワークベンチを再始動して参照を強制的にリリースしてください。3 つ目の項目で説明されている最後のシナリオ例では、「データベース・エクスプローラー」ビューを使用して、Cloudscape または Derby データベース接続から接続または切断を行うことができます。
リソース、例えばエンタープライズ Bean をサーバーにパブリッシュしているときに、EJB をテストするために Universal Test Client (UTC) を使用すると、JAR ファイルがロックされ、更新できません。この結果、ツールで行われた変更が EJB のテスト中にピックアップされません。UTC が EJB JAR ファイルをロードすると、アプリケーションが除去されるまで、またはサーバーが再始動されるまで、JAR ファイルはロックされたままです。
回避方法: アプリケーションのリソースがワークスペースの外で実行され、サーバー上で実行されていない開発環境で、UTC を使用してください。これは、「新規サーバー」ウィザードで構成することもできますが、後でサーバー・エディターを使用して、「パブリッシュ」オプションの下の「サーバーをワークスペース内のリソースで実行する」を選択することにより、変更することもできます。これによって、EJB JAR ファイル全体を完全に置き換える必要なく、EJB プロジェクト内の個々のファイルを更新することができます。
アプリケーションが完全にテストされたら、「サーバーをワークスペース内のリソースで実行する」パブリッシュ・オプションを使用して、サーバーにパブリッシュすることができます。