Glassfishドメイン間のIIOPで失われる例外メッセージ

StackOverflow https://stackoverflow.com/questions/2903938

  •  04-10-2019
  •  | 
  •  

質問

ステートレスセッションEJBを含む2つのGlassfish V2ドメインを実行しています。いくつかのケースでは、あるドメインのEJBが一方のドメインを呼び出す必要があります。

私の問題は、呼ばれるEJBが例外を除いて中止する場合、発信者は例外のメッセージを受け取らず、代わりに問題の診断にまったく役に立たない内部エラーを報告することです。何が起こるかはこれのようです：

  • 輸送層で、a org.omg.CORBA.portable.ApplicationException 作成されていますが、クラスを除く例外に関するすべての詳細情報がすでに失われています。

  • 中身 com.sun.jts.CosTransactions.TopCoordinator.get_txcontext(), 、トランザクションアスがロールバックされたステータスは org.omg.CosTransactions.Unavailable 投げられるために、それは包まれて数回渡され、最終的にこのエラーがユーザーに表示されます。

    org.omg.CORBA.INVALID_TRANSACTION:   vmcid: 0x0  minor code: 0  completed: No
at com.sun.jts.CosTransactions.CurrentTransaction.sendingRequest(CurrentTransaction.java:807)
at com.sun.jts.CosTransactions.SenderReceiver.sending_request(SenderReceiver.java:139)
at com.sun.jts.pi.InterceptorImpl.send_request(InterceptorImpl.java:344)
at com.sun.corba.ee.impl.interceptors.InterceptorInvoker.invokeClientInterceptorStartingPoint(InterceptorInvoker.java:271)
at com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeClientPIStartingPoint(PIHandlerImpl.java:348)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:284)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:184)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:186)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(BCELStubBase.java:225)

問題の実際の原因に関する情報を保存するためにここでできることはありますか？

役に立ちましたか？

解決 3

私はついにこれの底に到達しました：実際、GlassfishはIIOPを介して例外を非常に正しく送信し、すべてが必要に応じて機能します...あなたがこのような何かをしない限り：

try{
    ejb.getFoo();
}catch (Exception e){
    // try again
    ejb.getFoo();
}

ええ、例外を飲み込んだのは私たち自身のコードであり、例外のためにロールバックされた分散トランザクション内でトランザクションを要求するEJBメソッドを呼び出そうとしました。

他のヒント

問題の原因は、問題があるEJBをホストするドメインのサーバーログで利用できるようにする必要があります。

もう一方の端からより多くの情報を取得するのは難しいかもしれません...アプリケーションエクセプトが作成/スローされたときに失われた情報に適した問題がどの問題になるかわかりません。

完全なハックは、失敗したEJBを備えたプロジェクトに一連のカスタム例外クラスを作成することです。問題の可能性のある原因をカバーするために非常に細かい粒子を獲得し、問題の実際の位置を特定するのに十分な詳細を提供します。イェッキー...しかし、それは問題が提出され、修正が配布されるまで唯一の選択かもしれません。

問題の実際の原因に関する情報を保存するためにここでできることはありますか？

残念だけど違う。 ORBは、システムの例外（つまり、org.omg.corba。*）に通常のオブジェクトシリアル化を使用していません。これは、原因が失われることを意味します。 @vkraemerが言ったように、サーバーログに依存する必要があります。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top