[EJB3] RuntimeException et EJB : plantage en cascade

[thecaptain]

Bonjour à tous

J'ai récemment eu un souci avec les RuntimeException dans un projet Java EE. Le fait est que si un EJB en référence un autre (via @EJB) et que ce dernier lance une RuntimeException, toutes les injections @EJB sautent !

Voici l'exemple utilisé :

Code :

public class ProcessorBean { public String process() { throw new RuntimeException("error"); } } /* This is a sub-bean that throws a simple RuntimeException */

Code :

public class OtherBean  { public String hello() { return "processed by OtherBean"; } } /* Another sub-bean to test the catch-call (optional) */

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class TestBean
{
    @EJB
    private ProcessorLocal processor;
 
    @EJB
    private OtherLocal other;
 
    public String process()
    {
          String result = null;
          try
          {
              result = processor.process(); //will throws a RuntimeException
          }
          catch(Exception e)
          {
              result = other.hello(); //CRASH !!!! --> afther that processor.process() trhows a RuntimeException, all injections @EJB are down ! There will be a ejb.some_unmapped_exception written in the console.
          }
 
          return result;
    }
}

Afin de palier au problème, nous avons pensé à la solution suivante : utiliser les annotations pour faire du pré-processing avant la compilation. L'idée est d'encapsuler chacune des méthodes des classes annotées par un gros try/catch et de relancer une RemoteException (qui n'est pas une RuntimeException).

J'aimerais si possible avoir quelques retour la-dessus. Est-ce que quelqu'un a déjà eu ce problème ? Comment l'a-t-il contourné ? Est-ce que notre idée semble correcte ?

Merci d'avance !

@++

[longbeach]

Salut,
ton problème est intéressant.

Le comportement est normal puisque les RuntimeException et les RemoteException sont des system exceptions.
Quand le container rencontre une system exception, il y a 3 conséquences:
l'erreur est loggée, la transaction est rollbackée et le bean est abandonné (il n'y a plus de référence à ce bean qui du coup devient candidat pour le GC).

Solution:
ce que tu peux faire c'est transformé ta RuntimeException en une application exception :

Code :

1
2
3
 
@ApplicationException
public class MonException extends RuntimeException

[thecaptain]

Salut,

Merci de ta réponse, cela semble être tout à fait ce que nous cherchons à faire Je vais tester ça !
Ce qui est tout de même bizarre c'est que lorsque la transaction est "rollbackée" toutes les références aux EJB sont perdues... même ceux qui n'ont pas provoqué d'erreur
J'espère vraiment que Glassfish 3 enverra autre chose que des "ejb.some_unmapped_exception"

@++

[Grosgrognon]

Hello,

Je suis un collègue du Captain (d'ailleurs, si vous lui en voulez personnellement, faites-le moi savoir, et je forwarderai les beignes, promis ).


En fait, j'ai bien peur que ce ne soit pas la bonne solution : je ne pourrai décorer que les exceptions perso, pas celles de java (p. ex ArrayIndexOutOfBounds).

Peut-être devrions nous utiliser des Interceptor dans nos session beans...

Mééééeu! Je veux faire du code propre!

[manblaizo]

Envoyé par Grosgrognon

En fait, j'ai bien peur que ce ne soit pas la bonne solution : je ne pourrai décorer que les exceptions perso, pas celles de java (p. ex ArrayIndexOutOfBounds).

Bonjour,
C'est bizarre ce que vous cherchez à faire, il me semble. Les exceptions du genre ArrayIndexOutOfBounds sont des bugs dans votre code qui doivent normalement être traqués et corrigés avant la version finale à déployer.
Ce ne serait donc pas une bonne idée d'utiliser des blocs try/catch pour des RuntimeException.
Sinon, comme l'a dit longbeach, un ejb qui provoque une "system exception" est détruit pas le conteneur, la transaction est rollbackée, et donc normalement les références à d'autres beans sont perdues également.
Je pense qu'il vaut mieux essayer de corriger ces bugs potentiels dans votre code.

[tHE_fLAmMinG_mOE]

Bonjour,

je déterre ce sujet car j'ai été confronté à un problème de RuntimeException. Effectivement, l'annotation @ApplicationException permet au conteneur EJB de traiter les exceptions «unchecked» comme des «checked» (c'est-à-dire pas de rollback – sauf configuration contraire – ni de wrapping de l'exception dans une EJBException).

Envoyé par Grosgrognon

En fait, j'ai bien peur que ce ne soit pas la bonne solution : je ne pourrai décorer que les exceptions perso, pas celles de java (p. ex ArrayIndexOutOfBounds).

Je veux simplement ajouter que la décoration des exceptions standard de Java est aussi possible dans le descripteur ejb-jar.xml ==> voir ce billet

[longbeach]

Envoyé par tHE_fLAmMinG_mOE

Bonjour,

je déterre ce sujet car j'ai été confronté à un problème de RuntimeException. Effectivement, l'annotation @ApplicationException permet au conteneur EJB de traiter les exceptions «unchecked» comme des «checked» (c'est-à-dire pas de rollback – sauf configuration contraire – ni de wrapping de l'exception dans une EJBException).



Je veux simplement ajouter que la décoration des exceptions standard de Java est aussi possible dans le descripteur ejb-jar.xml ==> voir ce billet

Tout à fait.
Ci-joint un extrait de la spec ejb-3_0-fr-spec-ejbcore.pdf (JSR 220):

An application exception that is an unchecked exception is defined as an application exception by annotating it with the ApplicationException
metadata annotation, or denoting it in the deployment descriptor with the application-exception element.