JAVA EE - EJB/CDI/JPA: Gestion des exceptions

Question

conteneur EJB considère les exceptions de deux façons -

• Exception d'application - Si la règle d'entreprise est violée ou une exception se produit lors de l'exécution de la logique métier.

• Exception du système - Toute exception, qui n'est pas provoquée par une logique métier ou un code de gestion. RuntimeException, RemoteException sont SystemException. Par exemple, erreur lors de la recherche EJB. RuntimeException, RemoteException sont SystemException.

-> Est-ce que cela signifie que je dois utiliser des exceptions pour ma logique vérifié bussines? Comme ça ?

private void checkConstraints(Object object) throws ValidationException{ 
    Set<ConstraintViolation<Object>> constraintsAdress = this.getValidator().validate(object); 
    if(!constraintsAdress.isEmpty()){ 
     String fullErrorConstraint = ""; 
     for (ConstraintViolation<Object> constraint : constraintsAdress) { 
      fullErrorConstraint = fullErrorConstraint + constraint.getMessage() + "\n"; 
     } 
     throw new ValidationException(fullErrorConstraint); 
    } 
} 

@Override 
public long addCafe(Cafe cafe) throws ValidationException, DBException{ 
    this.checkConstraints(cafe.getAddress()); 
    for(FootballMatch footballMatch: cafe.getNextMatchesToWatch()){ 
     this.checkConstraints(footballMatch); 
    } 
    this.checkConstraints(cafe); 
    this.getManager().persist(cafe); 
    return cafe.getCafeID(); 
} 

mais ...

Une exception d'application ne se traduit pas automatiquement en marquant la transaction de restauration à moins que l'annotation ApplicationException est appliquée à la classe des exceptions et est spécifiée par la valeur de l'élément d'invalidation vrai ...

Je ne comprends pas pleinement plus ... Est-ce une bonne idée d'utiliser:

• @ApplicationException (rollback = true)?
• Et pouvez-vous utiliser celui-ci alors aussi pour faire une exception non vérifiée?

Thx à l'avance Vive Tom

Answer 1

• Imo @ApplicationException (rollback = true) est une bonne idée, depuis lors, le comportement du conteneur est défini. Dès qu'une telle exception se produit, l'annulation est certaine.
• Vous pouvez également déclarer des exceptions non contrôlées comme ApplicationExceptions.

Si vous êtes intéressé, j'ai comparé le comportement des tomee et en utilisant wildfly quelques tests: Baseclass-Bean for test

Les testclasses réels sont:

arquillian/wildfly et tomee/embedded

Certains tests sont désactivés puisque tomee semble ne pas supporter correctement "hérité".