Consider the typical case of selecting the proper content-type of the
response object: the resource method may choose to let runtime use
@Produces annotation or a custom Response may have its type() method
utilized from within the method implementation.
If neither @Produces is there or Response content-type is not set, the
runtime will default to application/octet-stream as per the spec.
The point is so far that the resource method has a choice not to worry
about setting the correct content type which can be very handy when
multiple response types are supported, example, xml or json - let the
runtime figure out whether it has to be xml or json response for every
individual response.
Now, what happens when ExceptionMapper creates a custom Response and it
does not set Response.type(), expecting the runtime to figure out the
correct content-type.
If the exception being mapped got originated from the resource method,
then the runtime can at least make an assumption that what can be
@Produce(d) by the method can also be produced by the mapper.
If the exception was thrown before the method was selected, all the
exception mapper can do to make sure that the custom response object if
any has the correct content type is to manually select this type, by
injecting HttpHeaders, analyzing the acceptable types, etc, which again
can be messy.
I'd like to propose for ExceptionMappers implementation have the same
support for choosing the way content-type is created as resource methods
have, and specifically, the runtime should check if ExceptionMappers
have @Produces or not.
So, if Response known to be originating from an exception mapper has no
content-type set, then the runtime will check that mapper's @Produces,
if it has @Produces then this is what is taken into the consideration,
if not - proceed as usual...
Does it make sense ?
thanks, Sergey