It could be related to the filter, though I can't say how. I'm using the
Jersey SpringServlet (Spring-enabled subclass of ServletContainer) as a
servlet instead of as a filter. I also don't do any Jersey configuration in
the web.xml (other than creating the servlet). Everything is in the Spring
config. Is there a particular reason you're running it as a filter? It seems
that by its nature of serving up content, it belongs more properly as a
servlet than as a filter. Also, why do you have ServletContainer configured
as both a servlet and a filter below? I can't think of anything else that
might help right now.
On Wed, Mar 9, 2011 at 2:59 AM, Casper Bang <casper.bang_at_gmail.com> wrote:
> Thanks for the suggestion Ryan, but I could observe no change in behavior.
> I wonder if it has something to do with the fact, or the way, that I am
> using Jersey as a filter.
>
> <servlet>
> <servlet-name>ServletAdaptor</servlet-name>
>
> <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
> <load-on-startup>1</load-on-startup>
> </servlet>
>
> <servlet-mapping>
> <servlet-name>ServletAdaptor</servlet-name>
> <url-pattern>/resources/*</url-pattern>
> </servlet-mapping>
>
> <filter>
> <filter-name>LoggingCachingFilter</filter-name>
>
> <filter-class>com.brunata.webmon.ws.LoggingCachingFilter</filter-class>
> <init-param>
> <param-name>cacheName</param-name>
> <param-value>LoggingCachingFilter</param-value>
> </init-param>
> </filter>
>
> <filter-mapping>
> <filter-name>LoggingCachingFilter</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
>
> <filter>
> <filter-name>ws-webmon</filter-name>
>
> <filter-class>com.sun.jersey.spi.container.servlet.ServletContainer</filter-class>
> <init-param>
>
> <param-name>com.sun.jersey.config.property.packages</param-name>
> <param-value>com.brunata.webmon.ws.resources;</param-value>
> </init-param>
> <init-param>
>
> <param-name>com.sun.jersey.config.property.JSPTemplatesBasePath</param-name>
> <param-value>/WEB-INF/jsp</param-value>
> </init-param>
> <init-param>
>
> <param-name>com.sun.jersey.config.property.WebPageContentRegex</param-name>
>
> <param-value>/(static|img|js|css|(WEB-INF/jsp))/.*</param-value>
> </init-param>
> <init-param>
>
> <param-name>com.sun.jersey.config.feature.ImplicitViewables</param-name>
> <param-value>false</param-value>
> </init-param>
> <init-param>
> <param-name>com.sun.jersey.config.feature.Redirect</param-name>
> <param-value>true</param-value>
> </init-param>
> </filter>
>
> <filter-mapping>
> <filter-name>ws-webmon</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
>
> /Casper
>
> On Tue, Mar 8, 2011 at 11:51 PM, Ryan Stewart <rds6235_at_gmail.com> wrote:
>
>> 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
>>>>
>>>>
>>>
>>
>