1

ステートレス セッション EJB を含む 2 つの glassfish v2 ドメインを実行しています。場合によっては、あるドメインの EJB が別のドメインの EJB を呼び出さなければならないことがあります。

私の問題は、呼び出された EJB が例外で異常終了した場合、呼び出し元が例外のメッセージを受信せず、代わりに問題の診断にまったく役立たない内部エラーを報告することです。何が起こるかは次のようです：

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

  • 内部com.sun.jts.CosTransactions.TopCoordinator.get_txcontext()では、ロールバックされたトランザクションのステータスにより、 aorg.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)

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

4

3 に答える 3

1

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

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

于 2010-05-28T18:18:10.193 に答える
1

問題の原因は、問題が発生した EJB をホストしているドメインのサーバー ログで確認できます。

反対側からより多くの情報を取得するのは難しいようです... ApplicationException が作成/スローされたときに失われた情報に対して、どの課題トラッカーが適切かわかりません。

完全なハックは、失敗した ejb を持つプロジェクトで一連のカスタム例外クラスを作成することです。問題の考えられる原因をカバーし、問題の実際の場所を特定するのに十分な詳細を名前に提供するために、それらを非常に細かく設定します。残念ですが、問題が報告され、修正プログラムが配布されるまでは、それが唯一の選択肢かもしれません。

于 2010-05-27T15:38:01.200 に答える
0

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

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

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

于 2010-06-24T07:38:19.613 に答える