CODEWITHSUNDEEP
jsfjakarta-eejsf-2glassfish-3ejb-3.1
Dfr
Dfr

Reputation: 4185

How to disable "WARNING: javax.ejb.EJBException"

i'm trying to get started with simple java ee application, using following components: JSF 2.0, JPA EclipseLink, Glasshfish 3.

Here is some snippets, backing bean:

@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 is a entity bean with bean validation annotations.

Now when user fills form incorrectly 'model.edit' throws EjbException, i handle it with catch, so saveRow backing bean method now look not so 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());
        }
    }
}

And still glassfish log filled with "WARNING: javax.ejb.EJBException" and long traces. I have some questions:

  1. How correct is my setup ? I know that jsf should handle BeanValidation, but it does not in my case.
  2. How to disable EJBException warnings, so server log will not be polluted
  3. Is there better way to handle EjbException ?

Upvotes: 2

Views: 1109

Answers (1)

esej
esej

Reputation: 3059

EJBExceptions triggers rollback of the current JTA transaction whether you catch them or not. The call to ProductsFacade#edit() starts a transaction (unless one is propagated to it, which doesn't seem to be the case here) since it is a call "from outside" into a SessionBean. If you don't want your transaction to rollback in these scenarios you have to validate the user/client input somehow somewhere before giving the broken Entity to the EntityManager.

There are several quirks and stuff to do here to avoid this situation. For example you can have the ProductsFacade handle transactions: @TransactionManagement(TransactionManagementType.BEAN), that would take away a big part of the point of using EJBs though. I do think this default behaviour is as it should be. If you don't want the Rollback in your log you can configure your logging level/etc - but I do think that EJB layered transactional rollbacks belongs in the log, it does definitely during development.

Upvotes: 1

Related Questions