Hi Martin,

When I examined the ResteasyViolationExceptionMapper, the problem appeared to be that ResteasyViolationException.getAccept() was always returning "text/plain" rather than the "application/json" which I was explicitly passing via the HTTP Accept header. So as I understand it, I think Resteasy should be executing this block of code:

// Check standard media types.
MediaType mediaType = getAcceptMediaType(exception.getAccept());
if (mediaType != null)
{
    builder.type(mediaType);
    builder.entity(new ViolationReport(exception));
    return builder.build();
}

where getAcceptMediaType(List<MediaType> accept) is where Resteasy implements the logic described in Chapter 51. Validation

I also think that any effort to convince the Resteasy developers that it was their problem would go something like this:

Resteasy: Does it work with just Resteasy and Hibernate Validator?
Me:          Yes, it does. (See resteasy-violator.tar)

Resteasy: Well, then...!

Cheers,

Chris

Martin Kouba wrote:

And you probably cannot even force them to implement this as it's not required by the spec.

My point is that it is documented Resteasy behaviour rather than part of the JAX-RS specification:

If any constraint violations are detected, Resteasy will return a report in one of a variety of formats. If one of "application/xml" or "application/json" occur in the "Accept" request header, Resteasy will return an appropriately marshalled instance of org.jboss.resteasy.api.validation.ViolationReport

See Chapter 51. Validation. Basically, including WELD is breaking this behaviour somehow.

And yes, I have considered writing a custom exception mapper as a last resort.

Also raised as [RESTEASY-1264] RESTEasy + WELD + HibernateValidator - ConstraintViolations always reported as MIME "text/plain". - JBos…