Hi, Actually I thought what you describe would already be the case.
RESTEasy has a class ResteasyViolationExceptionMapper [1] which creates HTTP responses in case of violation exceptions. I had a quick look at the same and from that I'd say the required code is basically in place already in this mapper, it is only not called for plain BV ValidationExceptions. Thus those are mapped to TEXT_PLAIN responses while ResteasyViolationExceptions (which are raised by the method validation integration) yield a nice XML/JSON responses. I recommend to open a RESTEASY issue for that. --Gunnar [1] https://github.com/resteasy/Resteasy/blob/master/jaxrs/providers/resteasy-validator-provider-11/src/main/java/org/jboss/resteasy/api/validation/ResteasyViolationExceptionMapper.java 2013/10/14 Emmanuel Bernard <emman...@hibernate.org> > I was once again working on the demo showing Bean Validation and its > integration inside Java EE 7. > When you put constraints on the method parameter of a JAX-RS call, you > get a nice rendering of the error on the client side (basically the > HTTP entity returns a JSON representation of the errors). > > But if from this method you call JPA or Bean Validation directly and a > ConstraintViolationException is raised, then this exception is processed > as a generic exception crossing RESTEasy. > > Would it make sense you think to treat ConstraintViolationException > raised by JAX-RS methods like we would do parameter or return value > exceptions? > > The error handling would be the same / unified. I might miss some parts > of the whole picture so this email is really for discussions. > > WDYT? > > Emmanuel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
