WebSphere Application Server Network Deployment, Version 6.0.x   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows

             目次と検索結果のパーソナライズ化

アプリケーション始動の問題

アプリケーションが始動しない、または始動してもエラーになる場合、さまざまな原因が考えられます。

アプリケーションの始動時に発生するエラーの種類を特定してください。
上記のどのエラーにも該当しない場合は、以下のようにします。

類似した問題が見つからない場合、または提供されている情報では問題が解決されない場合は 、IBM からのトラブルシューティングのヘルプ を参照してください。

java.lang.ClassNotFoundException: classnameBean_AdderServiceHome_04f0e027Bean

この種の例外は、Enterprise Bean またはデプロイしていない Enterprise Bean モジュールを含んでいる、 デプロイしていないアプリケーションを始動しようとした場合に発生します。

アセンブリー・ツールで作成された Enterprise JavaBeans モジュールは意図的に不完全な構成情報を持っています。 これらのモジュールをデプロイすると、このモジュールのデプロイメント記述子を読み取り、 プラットフォーム依存またはインストール・システム依存の設定を完了して 、Enterprise JavaBeans JAR ファイルに関連クラスを追加することにより、構成が完了します。

この問題を解決するには、以下の手順を実行してください。
  • アセンブリー・ツールおよび管理コンソールを使用してデプロイメント・コードを作成し、サーバーにアプリケーションまたは Enterprise JavaBeans モジュールをインストールします。
    1. 管理コンソールの アプリケーションまたは Enterprise JavaBeans モジュールをアンインストールします。
    2. アセンブリー・ツールの構成を行って、ターゲット・サーバーが WebSphere Application Server v6 といった WebSphere Application Server のインストール・システムであるようにします。 ターゲット・サーバーへのアクセス権を持っていない場合は、 c:¥temp といった仮のロケーションを指定できます。 仮のロケーションを指定することによってアセンブルを使用可能にし、Enterprise Bean のデプロイメント・コードを作成できるようになります。

      アセンブリー・ツールの構成 を参照してください。

    3. アセンブリー・ツールの Project Explorer ビューで、Enterprise JavaBeans モジュールを含むデプロイされていない .ear ファイル またはデプロイされていないスタンドアロン Enterprise JavaBeans JAR ファイルの エンタープライズ Bean (Enterprise JavaBeans) を右クリックしてから、「デプロイ」をクリックします。 アセンブリー・ツールが WebSphere Application Server のターゲット・サーバーにアクセスできる場合は、Enterprise JavaBeans 用のデプロイメント・コードが作成され、アセンブリー・ツールはターゲット・サーバーにアプリケーション・モジュールをインストールしようとします。 アセンブリー・ツールが WebSphere Application Server のターゲット・サーバーにアクセスできない場合またはインストールができない場合は、次のステップで作成されるデプロイメント・コードを使用します。

      アセンブリー・ツールの使用方法については、アプリケーションのアセンブル を参照してください。

    4. アセンブリー・ツールによって作成されたデプロイ済みのバージョンを、wsadmin $AdminApp install コマンドまたは管理コンソールを使用してインストールします。
  • wsadmin $AdminApp install コマンドを使用している場合は、そのコマンドをアンインストールしてから、-EJBDeploy オプションを使用して再インストールします。 install コマンドに $AdminConfig 保管コマンドが続くようにします。

ConnectionFac E J2CA0102E: Invalid EJB component: Cannot use an EJB module with version 1.1 using The Relational Resource Adapter

このエラーは、Enterprise JavaBeans 1.1 仕様に対して開発された Enterprise Bean が、WebSphere Application Server V5 J2C 準拠のデータ・ソース (デフォルトのデータ・ソース) と共にデプロイされている場合に発生します。 デフォルトでは、アプリケーション・アセンブリー・ツールを使用して、 WebSphere Application Server V4.0 で作成した永続エンタープライズ Bean により、 Enterprise JavaBeans 1.1 仕様が実現されます。 WebSphere Application Server V6 上で実行するためには、これらの Enterprise Beans を 、WebSphere Application Server V4.0 型のデータ・ソースに関連付ける必要があります。

Enterprise Beans についてのアプリケーションのマッピングを変更して 、1.x コンテナー管理パーシスタンス (CMP) Bean を V4.0 データ・ソースと関連付けるか、 または既存のデータ・ソースを削除し、同じ名前の V4.0 データ・ソースを作成します。

Enterprise Beans についてのアプリケーションのマッピングを変更するには 、WebSphere Application Server 管理コンソールで、問題のアプリケーションのプロパティーを選択し、 「リソース参照をリソースにマップ」、または「Map data sources for all 1.x CMP beans」を使用して 、Enterprise Bean が使用するデータ・ソースを切り替えます。 構成を保管して、アプリケーションを再始動します。

既存のデータ・ソースを削除して、同じ名前の V4.0 データ・ソースを作成するには、以下のようにします。
  1. 管理コンソールで、「リソース」 > 「JDBC プロバイダーの管理」 > 「JDBC_provider_name」 > 「データ・ソース」とクリックします。
  2. Enterprise JavaBeans 1.1 モジュールと関連付けられているデータ・ソースを削除します。
  3. 「リソース」 > 「JDBC プロバイダーの管理」 > 「JDBC_provider_name」 > 「データ・ソース (バージョン 4)」とクリックします。
  4. Enterprise JavaBeans 1.1 モジュールのデータ・ソースを作成します。
  5. 構成を保管して、アプリケーションを再始動します。

アプリケーションの始動時の NMSV0605E:「コンテキストからルックアップされた参照オブジェクト」というエラー

エラーの全文が以下のような場合:

[7/17/02 15:20:52:093 CDT] 5ae5a5e2 UrlContextHel W NMSV0605E: コンテキスト "java:" から名前 "comp/PM/WebSphereCMPConnectionFactory" でルックアップされた参照オブジェクトが JNDI Naming Manager に送られましたが、例外が発生しました。
参照データは次のとおりです。
     参照ファクトリー・クラス名: com.ibm.ws.naming.util.IndirectJndiLookupObjectFactory
     参照ファクトリー・クラスの場所の URL:
     参照クラス名: java.lang.Object
     タイプ: JndiLookupInfo
     コンテンツ: JndiLookupInfo: ; jndiName="eis/jdbc/MyDatasource_CMP"; providerURL=""; initialContextFactory=""

この場合は、問題は、CMP Enterprise Bean のサポートを意図したデータ・ソースが、Enterprise Bean に正しく関連付けされていないことである可能性があります。

この問題を解決するには、以下を行います。

  1. 管理コンソールの、データ・ソースの「一般プロパティー」パネルにある 「Use this Data Source in container managed persistence (CMP)」チェック・ボックスを選択します。
  2. 以下のいずれかの方法で、JNDI 名を確認してください。
    • 管理コンソールの「リソース」 > 「JDBC プロバイダーの管理」 > 「データ・ソース」 > 「JNDI 名」で指定したデータ・ソースの JNDI 名が、アセンブリー・ツールアプリケーションのアセンブルを行ったときに CMP または BMP のリソース・バインディングに対して指定された JNDI 名と一致していることを確認します。
    • J2EE アプリケーション開発者がコードで指定する、CMP または BMP リソース・バインディング の JNDI 名を確認します。アセンブリー・ツールで、デプロイ済みの .ear フォルダーを開き、 CMP または BMP リソース・バインディングで、エンティティー Bean の JNDI 名を探します。 名前が一致することを確認してください。

Java Native Interface (JNI) コードを使用するデプロイされたアプリケーションが開始しません。 [バージョン 6.0.1 以降]

JNI コードを使用するアプリケーションは、デプロイメントの後で開始しない場合があります。 JNI は、他の言語 (例えば、C、C++、およびアセンブリー) で書かれたアプリケーションおよびライブラリーと作動できるようするため、仮想マシン上で稼働する Java コードを許可します。 ご使用の J2EE アプリケーションが、32 ビット環境で JNI を使用する場合、コードは 64 ビット環境に再コンパイルされる必要があります。 JNI 仕様はバージョンごとに変更されることがあるため、コンパイルの後 に JNI 呼び出しが異なる場合があります。 WebSphere Application Server は、今では 64 ビット環境をサポートしています。

JNI コードを使用しない「Pure」Java アプリケーションの場合は、32 ビットから 64 への互換性は問題ではありません。

JSF 構成を使用するアプリケーションを実行中に構文解析エラーが発生します

プロファイル名に 2 バイト文字を使用している場合、 JavaServer Faces™ (JSF) 構成を使用するアプリケーションを実行すると、 構文解析エラーを受け取ります。 この問題は、jsf-ibm.jar の一部である JSF 構成に関連しています。 このファイルは、Rational® Application Developer で JSF アプリケーションをビルドする際に 組み込まれます。構成ファイルは、メインの faces-config.xml ファイル内のエンティティーを参照します。

プロファイルを作成するときは、2 バイト文字を使用しないでください。

zSeries ハードウェア上の 64 ビット Linux の Red Hat Enterprise Linux 4.0 上で実行中に、Java Server Faces (JSF) ランタイム例外が発生します [Linux] [バージョン 6.0.2]

以下の例外は、zSeries 上の 64 ビット Linux 用の Red Hat Enterprise Linux 4.0 上にある WebSphere Application Server 6.0.2 で実行中の、Java Server Faces (JSF) を使用しているアプリケーションの実行時に発生する可能性があります。 JSF コンポーネントが見つからないことに示すメッセージはアプリケーション固有のものですが、スタック・トレースの内容は同じです。

0000004a ServletWrappe E SRVE0068E: Could not invoke the service() method on servlet /TestScores.jsp.
Exception thrown : javax.servlet.ServletException: Component Not Found for identifier: text16'.
at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:638)
at com.ibm._jsp._TestScores._jspService(_TestScores.java:99)
at com.ibm.ws.jsp.runtime.HttpJspBase.service(HttpJspBase.java:88)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1282)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:673)
at com.ibm.wsspi.webcontainer.servlet.GenericServletWrapper.handleRequest(GenericServletWrapper.java:117)
at com.ibm.ws.jsp.webcontainerext.JSPExtensionServletWrapper.handleRequest(JSPExtensionServletWrapper.java:178)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:265)
at com.ibm.faces.context.MultipartExternalContextImpl.dispatch(MultipartExternalContextImpl.java:320)
at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:254)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:87)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:201)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1282)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:673)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:2905)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:220)
at com.ibm.ws.webcontainer.VirtualHost.handleRequest(VirtualHost.java:204)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:1829)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:84)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:469)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:408)
at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:101)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete(WorkQueueManager.java:566)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager.attemptIO(WorkQueueManager.java:619)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager.workerRun(WorkQueueManager.java:952)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker.run(WorkQueueManager.java:1039)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1455)
この問題は、 Development Kit の JIT コンパイラーのエラーが原因で発生します。 この問題を修正するには、サーバーを始動する前に、問題のメソッドの JIT コンパイラーを使用不可にします。 これを行うには、サーバー・プロセスで以下のように設定します。
export JITC_COMPILEOPT=NQCOMMONING_PUT{javax/faces/component/UIComponentBase}{getFacetsAndChildren}

更新したアプリケーションの再始動時に、ページが検出されないか、配列指標が範囲外であるか、 またはその他のエラーが発生する

アプリケーションが実行中に更新されると、WebSphere Application Server はアプリケーションまたは変更済みコンポーネントのみを 自動的に停止し、アプリケーション・ロジックを更新して、 停止したアプリケーションまたはそのコンポーネントを再始動します。 更新済みアプリケーションの再始動について詳しくは、IBM WebSphere Developer Technical Journal の System management for WebSphere Application Server V6 -- パート 5 Flexible options for updating deployed applications にある Fine-grained recycle behavior を参照してください。

再始動時に、ページが検出されないか、配列指標が範囲外であるか、またはその他のエラーが 発生する可能性があります。

このようなエラーの発生を最小限にするには、実稼働環境でアプリケーションを更新する前に、テスト環境でアプリケーションを更新します。 実稼働環境へ直接、変更を加えないでください。




関連タスク
デプロイメントのトラブルシューティング
関連情報
IBM WebSphere Developer Technical Journal: System management for WebSphere Application Server V6 -- Part 5: Flexible options for updating deployed applications
Common malpractices whitepaper (Eleven ways to wreck a deployment)
参照トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 10:13:28 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rtrb_appstart.html