+ Répondre à la discussion
Affichage des résultats 1 à 7 sur 7
  1. #1
    Membre Expert
    Avatar de thecaptain
    Étudiant
    Inscrit en
    décembre 2003
    Messages
    918
    Détails du profil
    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : décembre 2003
    Messages : 918
    Points : 1 121
    Points
    1 121

    Par défaut RuntimeException et EJB : plantage en cascade

    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 !

    @++

  2. #2
    Rédacteur/Modérateur
    Avatar de longbeach
    Inscrit en
    avril 2003
    Messages
    938
    Détails du profil
    Informations personnelles :
    Âge : 39

    Informations forums :
    Inscription : avril 2003
    Messages : 938
    Points : 2 022
    Points
    2 022

    Par défaut

    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

  3. #3
    Membre Expert
    Avatar de thecaptain
    Étudiant
    Inscrit en
    décembre 2003
    Messages
    918
    Détails du profil
    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : décembre 2003
    Messages : 918
    Points : 1 121
    Points
    1 121

    Par défaut

    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"

    @++

  4. #4
    Candidat au titre de Membre du Club
    Profil pro
    Inscrit en
    mai 2003
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : mai 2003
    Messages : 12
    Points : 10
    Points
    10

    Par défaut

    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!


  5. #5
    Membre éprouvé
    Profil pro
    Inscrit en
    janvier 2006
    Messages
    365
    Détails du profil
    Informations personnelles :
    Localisation : Maroc

    Informations forums :
    Inscription : janvier 2006
    Messages : 365
    Points : 491
    Points
    491

    Par défaut

    Citation Envoyé par Grosgrognon Voir le message
    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.
    SCJP 5 / SCBCD 1.3 Certified

  6. #6
    Membre actif
    Inscrit en
    novembre 2004
    Messages
    64
    Détails du profil
    Informations forums :
    Inscription : novembre 2004
    Messages : 64
    Points : 153
    Points
    153

    Par défaut

    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).

    Citation Envoyé par Grosgrognon Voir le message
    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

  7. #7
    Rédacteur/Modérateur
    Avatar de longbeach
    Inscrit en
    avril 2003
    Messages
    938
    Détails du profil
    Informations personnelles :
    Âge : 39

    Informations forums :
    Inscription : avril 2003
    Messages : 938
    Points : 2 022
    Points
    2 022

    Par défaut

    Citation Envoyé par tHE_fLAmMinG_mOE Voir le message
    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.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •