Have you tried with other content types than text/plain? Maybe try
application/xml. I use Tomcat as a servlet container, and I've never seen
the behavior you're describing on a 400 response. The only thing that jumps
out at me is that I don't use text/plain for the response.
On Tue, Mar 8, 2011 at 11:11 AM, Casper Bang <casper.bang_at_gmail.com> wrote:
> The closest related issue in the list history seems to be the following:
> http://java.net/projects/jersey/lists/users/archive/2008-01/message/88
>
> As expected, providing a custom error-page did not work - it's never
> consulted.
>
> On Tue, Mar 8, 2011 at 4:30 PM, Casper Bang <casper.bang_at_gmail.com> wrote:
>
>> I am mapping a custom ParserException to HTTP error 400 "Bad Request" with
>> a message/reason like the following:
>>
>> @Provider
>> public class ParserExceptionMapper implements
>> ExceptionMapper<ParserException> {
>> @Override
>> public Response toResponse(ParserException ex) {
>> return Response.status(400)
>> .entity("TEEEEEST")
>> .type("text/plain")
>> .build();
>> }
>> }
>>
>> But for some reason my deployment server (a Tomcat 6.0.29) omits the
>> message, even if the default error page clearly has support for it:
>>
>> HTTP Status 400 -
>> ------------------------------
>>
>> *type* Status report
>>
>> *message* **
>>
>> *description* *The request sent by the client was syntactically incorrect
>> ().*
>>
>>
>> A unit-test using Grizzly shows that Jersey is indeed sending
>> the appropriate response back:
>>
>> assertEquals( 400,
>> response.getClientResponseStatus().getStatusCode() );
>>
>> assertEquals("Bad Request",
>> response.getClientResponseStatus().getReasonPhrase());
>>
>> assertEquals("TEEEEEST", response.getEntity(String.class));
>>
>>
>> Which makes me wonder whether anyone on this list is familiar with
>> container rewrites of error responses, perhaps even Tomcat specifically. The
>> only thing I can think of trying, is providing my very own error page via
>> error-page declarations in web.xml but my gut feeling is that it won't help
>> since - again - the default error page already has support for showing
>> message/reason entity/payload.
>>
>> Any pointers and suggestions welcomed.
>>
>> /Casper
>>
>>
>