mensaje de excepción perderse en IIOP entre los dominios de GlassFish

Question

Me estoy quedando dos dominios que contienen GlassFish v2 EJB de sesión sin estado. En algunos casos, un EJB en un dominio tiene que llamar a uno en el otro.

Mi problema es que cuando los llamados aborta EJB con una excepción, la persona que llama no recibe el mensaje de excepción y en su lugar informa de un error interno que no es útil en absoluto en el diagnóstico del problema. Lo que pasa parece ser la siguiente:

• En la capa de transporte, se crea un org.omg.CORBA.portable.ApplicationException, que ya pierde toda la información detallada acerca de la excepción, salvo su clase.

• Dentro de com.sun.jts.CosTransactions.TopCoordinator.get_txcontext(), el estado del culo retrotraído la transacción provoca un org.omg.CosTransactions.Unavailable a ser lanzado, que se envuelve alrededor y pasó unas cuantas veces y finalmente resulta en este error que se muestra al usuario:

  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)
  

¿Hay algo que pueda hacer para preservar la información sobre la causa real del problema?

Answer 1

Finalmente llegué a la parte inferior de esto: en realidad, transmite Glassfish excepciones a través de IIOP muy correctamente y todo funciona como debería ... a menos que haga algo estúpido como esto:

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

Sí, fue nuestro propio código maldita que se tragó la excepción y trató de llamar a un método EJB transacción que requiera dentro de una transacción distribuida que ha sido revertida debido a la excepción.

Answer 2

La causa del problema debe estar disponible en el registro del servidor de los dominios que alojan el EJB que tenía un problema.

Suena como conseguir más información de vuelta desde el otro extremo puede ser difícil ... No sé cual seguimiento de incidencias sería el más adecuado para la información perdida cuando se crea el ApplicationException / tirado.

Un truco total sería para crear un conjunto de clases de excepción personalizada en el proyecto que tiene el EJB que ha fallado. Se podría hacer muy finos como para cubrir las posibles causas del problema y proporcionar suficientes detalles en su nombre para identificar la ubicación real del problema, también. Asqueroso ... pero que puede ser la única opción hasta que un problema se presentó y la solución se distribuye.

Answer 3

¿Hay algo que pueda hacer aquí para conservar información sobre el actual causa del problema?

Por desgracia, no. El ORB no utiliza serialización normal de objeto para excepciones del sistema (es decir, org.omg.CORBA. *), Lo que significa que se pierden causas. Como @vkraemer dijo, tendrá que depender de los registros del servidor.