Comment désactiver "AVERTISSEMENT: javax.ejb.EJBException"

Question

je suis en train de commencer avec application simple ee java, en utilisant des composants suivants: JSF 2.0, JPA EclipseLink, Glasshfish 3.

Voici quelques extraits, haricot dos:

@Inject 
private ProductsFacade model;  
public void saveRow(Products p) { 
     model.edit(p); 
} 

ProductsFacade:

@Stateless 
public class ProductsFacade extends AbstractFacade<Products> { 
    @PersistenceContext 
    private EntityManager em; 
    public void edit(Products entity) { 
     em.merge(entity); 
    } 
    .... 

Products est un bean entité avec annotations de validation de haricots.

Maintenant, lorsque l'utilisateur remplit incorrectement forme « model.edit » jette EDBException, je débrouille avec cran, de sorte saveRow méthode de sauvegarde haricots regarder maintenant pas si concise:

public void saveRow(Products p) { 
    try { 
     model.edit(p); 
    } catch (EJBException e) { 
     if(e.getCause().getClass().getName().equals("javax.validation.ConstraintViolationException")) { 
      handleConstraintViolation((ConstraintViolationException)e.getCause()); 
     } 
    } 
} 

Et encore GlassFish journal rempli de " ATTENTION: javax.ejb.EJBException "et longues traces. J'ai quelques questions:

1. Quelle est la configuration correcte? Je sais que jsf devrait gérer BeanValidation, mais ce n'est pas le cas dans mon cas.
2. Comment désactiver les avertissements EJBException, afin que le journal du serveur ne soit pas pollué
3. Existe-t-il une meilleure façon de gérer EjbException?

Answer 1

EJBException s déclenche l'annulation de la transaction JTA en cours, que vous les récupériez ou non. L'appel à ProductsFacade#edit() démarre une transaction (à moins que l'on ne la propage, ce qui ne semble pas être le cas ici) puisque c'est un appel "de l'extérieur" dans un SessionBean. Si vous ne voulez pas que votre transaction soit annulée dans ces scénarios, vous devez valider l'entrée utilisateur/client quelque part avant de donner le code Entity au EntityManager.

Il y a plusieurs bizarreries et autres choses à faire ici pour éviter cette situation. Par exemple, vous pouvez avoir les transactions ProductsFacade gérer: @TransactionManagement(TransactionManagementType.BEAN), ce qui enlèverait une grande partie de l'utilisation des EJB. Je pense que ce comportement par défaut est comme il se doit. Si vous ne voulez pas le Rollback dans votre journal, vous pouvez configurer votre niveau de journalisation/etc - mais je pense que les rollbacks transactionnels en couches EJB appartiennent au log, il le fait définitivement pendant le développement.