message d'exception se perdre dans IIOP entre les domaines GlassFish

Question

Je suis en cours d'exécution deux domaines GlassFish v2 contenant EJB session sans état. Dans quelques cas, un EJB dans un domaine doit appeler l'un dans l'autre.

Mon problème est que lorsque les Abandonne EJB appelé à une exception, l'appelant ne reçoit pas le message de l'exception et des rapports au lieu d'une erreur interne qui n'est pas utile du tout pour diagnostiquer le problème. Ce qui se passe semble être ceci:

• A la couche de transport, un org.omg.CORBA.portable.ApplicationException est créé, qui perd déjà toutes les informations détaillées au sujet de l'exception à l'exception de sa catégorie.

• com.sun.jts.CosTransactions.TopCoordinator.get_txcontext() A l'intérieur, l'état de l'âne de transaction a été annulée provoque de nouveau une org.omg.CosTransactions.Unavailable à être jeté, ce qui est enveloppé et passé autour de plusieurs fois et finit par entraîner dans cette erreur affiché à l'utilisateur:

  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)
  

Est-ce que je peux faire ici pour conserver des informations sur la cause réelle du problème?

Answer 1

J'ai finalement eu au fond de ceci: en fait, Glassfish exceptions par IIOP transmet correctement tout à fait et tout fonctionne comme il se doit ... à moins que vous fassiez quelque chose idiote comme ceci:

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

Oui, il était notre propre code damn qui a avalé l'exception et a essayé d'appeler une méthode EJB transaction nécessitant au sein d'une transaction distribuée qui a été annulée en raison de l'exception.

Answer 2

La cause du problème devrait être disponible dans le journal du serveur des domaines hébergeant l'EJB qui avait un problème.

On dirait obtenir plus d'information en arrière de l'autre extrémité peut être difficile ... Je ne sais pas ce qui serait suivi question le droit pour les informations perdues lorsque le ApplicationException est créé / jeté.

Un hack total serait de créer un ensemble de classes d'exception personnalisée dans le projet qui a le ejb qui a échoué. Vous les rendre à grains très fins pour couvrir les causes probables du problème et de fournir suffisamment de détails dans leur nom pour identifier l'emplacement réel du problème, aussi. Dégueu ... mais ce peut être le seul choix jusqu'à ce qu'un problème se déposé et le correctif est distribué.

Answer 3

  

Est-ce que je peux faire ici pour   préserver les informations sur le réel   cause du problème?

Malheureusement, non. L'ORB n'utilise pas sérialisation objet normal des exceptions du système (à savoir org.omg.CORBA. *), Ce qui signifie que les causes sont perdues. Comme @vkraemer dit, vous devrez compter sur les journaux de serveur.