Unable to catch ConstaintValidationException from an ExceptionMapper

Question

I'm writing a REST application using WildFly 8 (JAX-RS 2.0, EJB 3.2 and JPA 2.1).

I have a JAX-RS resource which is also an EJB (stateless session bean with implicit container-managed transactions):

@Path("myresources")
@Stateless
public class MyResource {
    @PersistenceContext(name = "MyDataSource")
    private EntityManager em;

    @POST
    public Response create() {
        MyEntity invalidBean = new MyEntity();
        em.persit(invalidBean);
        ...
    }
}

MyEntity is decorated with bean validation annotations:

@Entity
public class MyEntity {
    @NotNull
    private String field;
    ...
}

Finally, I have defined an ExceptionMapper for ConstraintViolationException:

@Provider
public class ConstraintViolationExceptionMapper implements ExceptionMapper<ConstraintViolationException> {
    @Override
    public Response toResponse(ConstraintViolationException exception) {
        ...
    }
}

When MyResource.create is called, I expect the following behavior:

1. The invalid bean is saved using JPA
2. The end of my service implementation is reached without any exception
3. A commit is triggered by the container (container-managed transaction)
4. JTA launches bean validation to check constraints on the saved bean
5. A ConstraintViolationException is thrown
6. JAX-RS dispatches it to my ConstraintViolationExceptionMapper

However, this does not work properly: the ConstraintViolationException is actually thrown, but deeply wrapped inside an EJBTransactionRolledbackException. So, my ExceptionMapper does not catch it.

I already configured ConstraintViolationException to be an ApplicationException (following this guide). Thus, I'm now able to catch ConstraintViolationException when thrown from my own code, but still not when thrown by JTA.

This thread seems related, but I would prefer to avoid:

• explicit transaction handling
• vendor-specific solutions

Any idea to solve this problem?

Thanks!

Answer 1

I think the problem is what your expectation is. There are potentially two points where validation can occur. Your example triggers Bean Validation as part of JPA life cycle events (persist in this case). Since we are at this stage already talking to a database it is wrapped in a rollback exception.

The other approach is to use the JAX-RS validation of the input. For example I would have expected your example to look like:

@Path("myresources")
@Stateless
public class MyResource {
    @PersistenceContext(name = "MyDataSource")
    private EntityManager em;

    @POST
    @ValidateOnExecution
    public Response create(@Valid MyEntity entity) {
        em.persit(entity);
        ...
    }
}

Now your posted parameters are converted into a MyEntity instance and validated as part of the request processing.

Answer 2

I have faced exactly the same issue with Glassfish 4 (Jersey 2 + EclipseLink). As @Hardy mentioned, the problem here is that JPA is throwing the exception as part of its lifecycle - in my case, because of the <validation-mode>CALLBACK</validation-mode> in my persistence.xml.

The @ApplicationException mechanism with the ejb-jar.xml file is working indeed, so the validation is not triggered inside your EJB method but at commit time. Then, the behaviour is:

1. The container starts the transaction.
2. The EJB method persist the invalid entity without errors (There is no exception to map).
3. The container commits the transaction, and the JPA lifecycle validates the entity.
4. A ConstraintViolationException is thrown, it causes a RollbackException, which in turn causes the final EJB Exception. Note that this exception is not thrown by your EJB.

The solution I found was to synchronize the persistence context in the method execution via EntityManager#flush(). This triggers the JPA validation and I am able to map the exception with the ExceptionMapper provider, since the ConstraintViolationException is always thrown inside my EJB code.

In my opinion, this solution is cleaner than unwrapping the EJB exception until the cause is the ConstraintViolationException you are looking for.

I have uploaded a sample project to GitHub to reproduce the solution, the important files are:

• src/main/java/org/example/services/MyServiceImpl.java (CDI bean)
• src/main/java/org/example/rest/MyResource.java (EJB and JAX-RS resource)
• src/main/webapp/WEB-INF/ejb-jar.xml.

If you have any doubts, please let me know.