テストおよび公開 (サーバー) ツールのリリース情報

© Copyright International Business Machines Corporation 2006. All rights reserved.

リリース情報

1.0 制限
   1.1 「サーバーにコピーされる最小化アプリケーション・ファイル」オプションは、WebSphere Application Server 6.0.2.5 以降でサポートされる
   1.2 複数の EAR プロジェクト内で共用される EJB モジュールの除去
   1.3 マルチスレッド WebSphere アプリケーション・クライアントの実行
2.0 既知の問題と回避方法
   2.1 ホット・メソッド置換がデバッグ・モードでの再開後に適用されない
   2.2 「共用 WebSphere サーバーの管理」ダイアログ・ボックスの「除去」ボタンが機能しない
   2.3 「新規サーバー」ウィザードが正しいポート情報を取得しない場合がある
   2.4 64 ビット・マシンでの WebSphere Application Server 用プロファイルの作成
   2.5 ネットワーク接続が失われた後の RMI 接続確立時の長い遅延
   2.6 アプリケーション・デプロイメント記述子エディターの「デプロイメント」ページでのさまざまな変更をサーバーが取得できない
   2.7 ユーティリティー JAR ファイルを Web ライブラリーに追加すると java.lang.NoClassDefFoundError エラーが起きる
   2.8 WebSphere Application Server の V6.0 と V6.1 の間ではセキュアな SOAP 接続が共存できない
   2.9 リモート・サーバーが停止されたときに、「新規サーバー」ウィザードの完了に長い時間がかかる場合がある
   2.10 EarContent ディレクトリー内に .war ファイル拡張子が含まれる EAR アプリケーションの公開が失敗する
   2.11 リモート WebSphere Application Server V5.1 のデプロイメントおよび公開のディレクトリーの変更内容を反映できない
   2.12 大規模なアプリケーションの公開が以前のバージョンよりも遅くなる
   2.13 保護された WebSphere Application Server v6.1 のサーバー接続タイプの切り替え
   2.14 「テーブルおよびデータ・ソース・クリエーター」ウィザードの使用時に、TargetInvocationException エラーを検出する
   2.15 「サーバー」ビューからサーバーを停止する場合に、サーバーが完全に停止しない場合がある
   2.16 Universal Test Client (UTC) から EJB を実行した後に、EJB JAR の変更が反映されない

1.0 制限

1.1「サーバーにコピーされる最小化アプリケーション・ファイル」オプションは、WebSphere Application Server 6.0.2.5 以降でサポートされる

サーバーにコピーされる最小化アプリケーション・ファイル」オプションは、WebSphere® Application Server 6.0.2.5 以降でサポートされています。 WebSphere Application Server V6.0 サーバー・エディターには、このオプションのチェック・ボックスがあります。このオプションは、バージョン 6.0.2.5 より前のサーバー用に選択された場合には無視されます。   

1.2 複数の EAR プロジェクト内で共用される EJB モジュールの除去

エンタープライズ 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)
 

1.3 マルチスレッド WebSphere アプリケーション・クライアントの実行

Eclipse ランタイム環境と WebSphere ランタイム環境の間のさまざまな振る舞いおよび相互作用のために、「アプリケーション・クライアントの起動構成 (Application Client Launch Configurations)」ダイアログ・ボックスを通じてマルチスレッド WebSphere アプリケーション・クライアントを実行する場合には、幾つかの追加手順が必要となります。「アプリケーション・クライアントの起動構成 (Application Client Launch Configurations)」ダイアログ・ボックスは、製品のツールバーで「実行」>「実行...」を選択した場合に、J2EE パースペクティブから使用できます。  クライアントが複数のスレッドを使用する場合、または Swing などの追加のスレッドを使用する可能性があるフレームワークを使用する場合は、以下の追加手順も実行する必要があります。 

  1. 「アプリケーション・クライアントの起動構成 (Application Client Launch Configurations)」ダイアログ・ボックスで、「引数」タブを選択します。  「VM 引数」テキスト・ボックスで、以下のパラメーターを指定します。
    -Dosgi.noShutdown=true
  2. クライアント・アプリケーションが System.exit() を呼び出すことを確認します。

これを指定しないと、クラス・ロードに関連する問題、またはアプリケーションの実行完了後に終了しない Java 仮想マシン (JVM) に関連する問題が発生する場合があります。

2.0 既知の問題と回避方法

2.1 ホット・メソッド置換がデバッグ・モードでの再開後に適用されない

以下の構成を持つプロジェクト (例えば、アプリケーション・クライアント・プロジェクト) があるとします。

「デバッグ」ビューの「再開」ボタンが正常に機能しない可能性があります。  例えば、サーバー上でアプリケーションをデバッグ・モードで実行した際、実行時にソースの変更を試行してから、「再開」ボタンを使用してアプリケーションのデバッグを続行した場合などです。 ホット・メソッド置換によるソース・コードへの変更が適用されていない可能性があります。
実行時の変更を有効にするには、「再開」ボタンを 2 回クリックしてみてください。 
注:  この問題は、Java のプロジェクト・ファセットをバージョン 5.0 に設定した場合には発生しません。

2.2 「共用 WebSphere サーバーの管理」ダイアログ・ボックスの「除去」ボタンが機能しない

「共用 WebSphere サーバーの管理」ダイアログ・ボックスの「除去」ボタンが正しく機能しません。
ヒント: 「共用 WebSphere サーバーの管理」ダイアログ・ボックスを開くには、次のようにします。

  1. ツールバーで、「ウィンドウ」>「設定」を選択します。「設定」ダイアログがオープンします。
  2. 左側のペインで、「サーバー」>「WebSphere」>「WebSphere v51」を選択します。
  3. 右のペインで、「共用 WebSphere サーバー」フィールドの隣の「管理」ボタンをクリックします。「共用 WebSphere サーバーの管理」ダイアログ・ボックスが開きます。

「除去」ボタンを使用すると、サーバーは除去済みであると示されます。しかし、このダイアログ・ボックスを終了してから、もう一度開いて、リモート・サーバー情報を最新表示すると、すでに除去したはずのサーバーがダイアログ・ボックス内に残っています。 

この問題に対処するには、次の手順に従って、共用サーバー項目を手動で除去します。

  1. 以下のディレクトリー内に置かれている id.txt ファイルを開きます。
    <directory>/plugins/com.ibm.etools.websphere.tools*/properties
    ここで、<directory> は、Agent Controller のインストール・ディレクトリーです。
  2. 除去しようとしている共用サーバーを参照している項目を削除します。
  3. サーバーの作成中に該当共用サーバー用に指定した WebSphere デプロイメント・ディレクトリーおよびそのすべてのサブディレクトリーを除去します。 WebSphere デプロイメント・ディレクトリーの下の除去対象のサブディレクトリーの例には、config、installedApps、temp、および他のすべてのディレクトリーと、そのディレクトリーの下に置かれているファイルがあります。
  4. 「共用 WebSphere サーバーの管理」ダイアログ・ボックスで、ホスト名を指定し、「更新」ボタンをクリックして、共用サーバーが正常に除去されたことを確認します。

2.3 「新規サーバー」ウィザードが正しいポート情報を取得しない場合がある

同じ WebSphere Application Server v6.x プロファイル内に、IBM HTTP Server などの追加のサーバーがインストールされている場合、「新規サーバー」ウィザードの「WebSphere サーバーの設定」ページに、正しいリモート・メソッド呼び出し (RMI) または SOAP のポート番号が見つからないことがあります。    また、管理コンソールのポート番号が取得されない場合もあります。
「新規サーバー」ウィザードがサーバー用に定義された実際のポート番号を見つけられない場合、このウィザードのデフォルトの動作では、ポート・フィールドにデフォルトのポート番号 (RMI の場合は 2809、SOAP の場合は 8880) が事前に取り込まれます。 
適切でないポート番号が定義されている場合は、以下の問題が発生する可能性があります。

回避方法:

  1. サーバー構成ファイルを参照して、構成済みプロファイルのポートの値を判別します。ポートの値は、以下のディレクトリー内の 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
  2. サーバーに接続するには、サーバーの作成時に正しい RMI または SOAP ポート番号を指定します。
  3. 管理コンソールを開始するには、外部 Web ブラウザーを使用して、次のように正しい管理コンソール・ポートへの URL をアドレス・フィールドに入力します。
    http://<machine_name>:<WC_adminhost>/IBM/console
    たとえば、http://localhost:9060/IBM/console と入力します。
  4. サーバー上でアプリケーションを実行するには、「サーバーで実行」コマンドを発行してください。Web ブラウザーが開いたら、サーバー用に定義した HTTP トランスポートのポート番号を使用して、URL を訂正してください。 
    http://<machine_name>:<WC_defaulthost>/<ContextRoot>/<application_start_page>
    たとえば、  http://localhost:9080/MyApplication/index.jsp と入力します。
    注: 「サーバー」ビューで自動的に定義されたサーバーは、実際のサーバーの正しいポート番号を参照していないことがあります。この場合は、上記と同じ回避方法を使用してください。

 

2.4 64 ビット・マシンでの WebSphere Application Server 用プロファイルの作成

プロファイル管理ツールは、各ランタイム環境用にプロファイルを作成する WebSphere Application Server のツールです。ワークベンチを使用して、WebSphere Application Server のプロファイル管理ツールを開始することができます。 ただし、プロファイル管理ツールは 64 ビット・プロセッサーでは動作しませんので、代わりに WebSphere Application Server によって提供されている manageprofiles コマンド行ツールを使用してください。

2.5 ネットワーク接続が失われた後の RMI 接続確立時の長い遅延

Windows オペレーティング・システムでリモート・メソッド呼び出し (RMI) ポートを使用して WebSphere Application Server v6.x に接続している場合、ネットワーク接続が失われた後、サーバーへの接続の確立時に長い遅延が生じることがあります。これが起きる可能性があるのは、サーバーがローカルであって、ネットワーク接続が単に一時的に失われただけの場合です。このことは、ワイヤレス・ネットワーク環境ではよくあることです。
サーバーが始動済みであることが分かっており、「サーバー」ビュー内での状況として「停止済み」または「始動中」が表示されている場合は、サーバー接続を RMI から SOAP に切り替えることによって、サーバーへの接続を確立できるかどうかを調べてみてください。 サーバーの状況は、「始動済み」に変わります。 

ワイヤレス・ネットワーク環境で、サーバーへの接続を確立するときに利用できるオプションをいくつか以下に示します。

2.6 アプリケーション・デプロイメント記述子エディターの「デプロイメント」ページでのさまざまな変更をサーバーが取得できない

アプリケーションの再公開、アプリケーションの再始動、またはアプリケーションのアンインストールおよび再インストールは、アプリケーション・デプロイメント記述子エディターの「デプロイメント」ページで定義された、さまざまなリソースの変更をサーバーに適用するには、十分なアクションではありません。エディターの「デプロイメント」ページでのデータ・ソースのデータベース名への変更は、サーバーが取得できない変更であることが分かっており、他にもサーバーが取得できない変更は幾つか存在する可能性があります。
回避方法として、以下の手順を完了して変更をサーバーに適用してください。

  1. サーバーを停止します。
    1. 「サーバー」ビューでサーバーを右クリックし、「停止」を選択します。
    2. 「サーバー」ビューでサーバーの状況が「停止済み」と表示されるまで待ってから、次の手順を続行します。 
  2. ワークベンチを開始します。
    注: サーバーの始動に失敗した場合は、オペレーティング・システムの機能を使用して、そのサーバーが実行されている java プロセスを停止する必要があります。 あるいは、ワークベンチを再始動してから、サーバーの始動を再試行することもできます。
  3. サーバーを始動します。
    1. 「サーバー」ビューで、サーバーを右クリックし、「始動」を選択します。
    2. 「サーバー」ビューで、再公開が完了してサーバーおよびアプリケーションの状況に「始動済み 」と表示されるまで待ってから、次の手順に進みます。
  4. 例えば、「サーバーで実行」コマンドを使用して、サーバー上でアプリケーションを実行します。  その結果、サーバーはアプリケーション・デプロイメント記述子エディターによる変更を取得できるようになります。 

2.7 ユーティリティー JAR ファイルを Web ライブラリーに追加すると java.lang.NoClassDefFoundError エラーが起きる

Web プロジェクトの Web ライブラリーにユーティリティー JAR ファイルを追加し、コードでその JAR ファイル内のクラスを参照する場合、サーバー上でアプリケーションの実行を試行すると  java.lang.NoClassDefFoundError エラーが発生する場合があります。
この問題を回避するには、以下の手順に従って、ユーティリティー JAR ファイルを EAR モジュールに追加してから、その JAR ファイルを Web プロジェクトの J2EE モジュール依存関係に追加します。

  1. ユーティリティー JAR ファイルを EAR モジュールに追加します。 詳しくは、製品のヘルプの『プロジェクト・ユーティリティー JAR ファイルの追加』トピックを参照してください。
  2. Web プロジェクトを右クリックして、「プロパティー」を選択します。 「プロパティー」ダイアログ・ボックスが開きます。
  3. J2EE モジュール依存関係 (J2EE Modules Dependencies)」を選択します。   
  4. JAR/モジュール」列の下の「J2EE モジュール」タブで、ユーティリティー JAR ファイルの横のチェック・ボックスを選択します。

2.8 WebSphere Application Server の V6.0 と V6.1 の間ではセキュアな SOAP 接続が共存できない

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 接続を使用します。

 

2.9 リモート・サーバーが停止されたときに、「新規サーバー」ウィザードの完了に長い時間がかかる場合がある

リモート・サーバーを停止した場合、「終了」ボタンをクリックしたときに、「新規サーバー」ウィザードが完了するまでに要する時間が長くなることがあります。  回避方法は、「新規サーバー」ウィザードの「終了」ボタンをクリックする前に、リモート・サーバーを始動することです。

2.10 EarContent ディレクトリー内に .war ファイル拡張子が含まれる EAR アプリケーションの公開が失敗する

.war 拡張子を持つファイルが EAR プロジェクトの EarContent フォルダー内に配置され、application.xml で Web モジュールとして定義されていない場合、エンタープライズ・アプリケーションはサーバーでの公開に失敗し、以下のようなエラー・メッセージが出されます。
org.eclipse.jst.j2ee.commonarchivecore.internal.exception.OpenFailureException: IWAE0034E "D:¥myworkspace¥PublishEAR¥EarContent" 内のネストされたアーカイブ "abc.war" を開くことができませんでした。

このエラーの原因は、ワークベンチがそのファイルを Web モジュールとして正しく処理できなかったことにあります。以下の回避方法のいずれかを選択してください。 

 

2.11 リモート WebSphere Application Server V5.1 のデプロイメントおよび公開のディレクトリーの変更内容を反映できない

リモート WebSphere Application Server V5.1 またはリモート WebSphere Application Server V5.1 Express Edition では、デプロイメント・ディレクトリーおよび公開ディレクトリーをサーバー・エディターで変更してからそのアプリケーションを再公開した場合、アプリケーションは引き続き前の宛先への公開を続けます。その結果、公開ディレクトリーおよびデプロイメント・ディレクトリーの変更内容は適用されません。  この問題が起きるのは、ローカル・コピーまたは FTP 方式の使用時です。
この問題を回避するには、ワークベンチを再始動します。これにより、公開ディレクトリーおよびデプロイメント・ディレクトリーの構成変更が有効化されるはずです。 

2.12 大規模なアプリケーションの公開が以前のバージョンよりも遅くなる

プロジェクトの保管に対するさらに柔軟なアプローチをサポートするために、アプリケーションの公開技法が変更されました。 アプリケーションは、サーバーに公開される前にコピーされるようになりました。 アプリケーションが大規模な場合 (例えば、100 メガバイトを超えるような場合)、以前のバージョンでかかった時間に加えて、この公開コマンド用に使用されるコピー操作にかかる時間が追加されます。     

現在のところ、回避方法はありません。 IBM では、この新しいコピー操作をほとんどの場合に実行する必要がなくなるような更新への取り組みを行っています。

2.13 保護された WebSphere Application Server v6.1 のサーバー接続タイプの切り替え

保護された WebSphere Application Server v6.1 が始動済みの場合に、サーバー・エディターでサーバーの接続タイプをリモート・メソッド呼び出し (RMI) または SOAP に変更すると、そのサーバー・エディターで変更内容を保管した後で、以下の公開の失敗エラー・メッセージが表示される可能性があります。 
サーバーが始動していないため、公開が実行されません。サーバーを開始してから、公開操作を行ってください。 
このエラーは、無視しても構いません。 オプションで、「サーバー」ビューのサーバーの状況が「始動済み」になったら、公開コマンドを完了することができます (「サーバー」ビューで、サーバーを右クリックし、「公開」を選択します)。

2.14 「テーブルおよびデータ・ソース・クリエーター」ウィザードの使用時に、TargetInvocationException エラーを検出する

「テーブルおよびデータ・ソース・クリエーター」ウィザードを使用してデータ・ソースを生成しようとした場合、「テーブルおよびデータ・ソース作成の結果」ダイアログ・ボックスの「詳細」セクションに TargetInvocationException エラーが示されることがあります。
TargetInvocationException エラーは、同じ Java Naming and Directory Interface (JNDI) 名で定義されたデータ・ソースを含むプロジェクト交換をインポートした場合に発生する可能性があります。
TargetInvocationException エラーに対処するには、同一の JNDI 名の付いたデータ・ソースがすでにワークベンチに定義されているかどうかを確認します。  定義されている場合は、アプリケーション・デプロイメント記述子エディターの「デプロイメント」ページからそのデータ・ソースを削除し、別の JNDI 名を使用してデータ・ソースを再作成します。  JNDI 名は、エンタープライズ Bean をデータ・ソースにバインドする際に使用される命名およびルックアップ・サービスであるため、固有のものである必要があります。

2.15 「サーバー」ビューからサーバーを停止する場合に、サーバーが完全に停止しない場合がある

「サーバー」ビューからサーバーを停止したときに、サーバーが完全に停止しない場合があります。「サーバー」ビューには「停止済み」と表示されますが、サーバー・プロセスは応答不能状態にあることがあります。  これは通常、アプリケーションまたはワークベンチなどの成果物が、サーバー上のクラスへの参照を保持し続けている場合に発生します。 以下はシナリオ例です。

制限事項:  Cloudscape または Derby の構成上の制限のため、単一の Cloudscape または Derby データベースへの複数の接続はサポートされていません。 データベース・エクスプローラーからデータベースへのデータベース接続を保守する場合、サーバーがデータ・ソースを通じて別の Cloudscape 接続または Derby 接続の作成を試行すると、2 番目の接続は失敗します。そのため、サーバーが Cloudscape または Derby データベースへの接続を確立するためには、まずデータベース・エクスプローラーから接続を閉じる必要があります。

 

この問題を回避するには、オペレーティング・システムの機能を使用して、そのサーバーが実行されている java プロセスを停止する必要があります。あるいは、ワークベンチを再始動し、参照を強制的に解放することもできます。 3 番目に解説した最後のシナリオ例では、データベース・エクスプローラー・ビューを使用して、Cloudscape または Derby データベース接続に接続してから切断することができます。

2.16 Universal Test Client (UTC) から EJB を実行した後に、EJB JAR の変更が反映されない

サーバーにリソース (例えば、エンタープライズ Bean) を公開する場合に、Universal Test Client (UTC) を使用して EJB のテストを行うと、JAR ファイルがロックされて、更新できなくなる可能性があります。そのため、EJB のテスト中にツールで行われた変更が反映されなくなります。 UTC が EJB JAR ファイルをロードすると、その JAR ファイルは、アプリケーションが除去されて再度追加されるか、サーバーが再始動されるまで、ロックされたままとなります。

この問題を回避するには、アプリケーションのリソースがワークスペースの外で実行され、サーバー上では実行されない開発環境で UTC を使用することです。これは、「新規サーバー」ウィザードを使用して構成するか、サーバー・エディターを使用して「公開」オプションの「サーバーをワークスペース内のリソースで実行する」を選択することで、後から変更することもできます。 これにより、EJB JAR ファイル全体の完全な置換を必要とせずに、EJB プロジェクト内の個々のファイルを更新することができます。

アプリケーションのテストが完了すると、「サーバーをサーバー上のリソースで実行」公開オプションを使用して、サーバーに公開できるようになります。