I tried out the servlet/filter thing in Tomcat, and I don't get any
unexpected results. I added a context to Tomcat (just created a directory in
<tomcat home>/webapps) and put in a basic web.xml and a servlet/filter class
that always returns a 400 response of type text/plain just like you're
describing. When invoking it as either a filter or a servlet, I get a plain
text page with the error message on it, as expected. I tried it in Tomcat
6.0.32 and 7.0.10. If you can run the same kind of test on your Tomcat
server, it might give you some insight. Here are the files I used:
<web-app xmlns="
http://java.sun.com/xml/ns/javaee"
xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0"
metadata-complete="true">
<filter>
<filter-name>foo</filter-name>
<filter-class>com.MyServletAndFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>foo</filter-name>
<url-pattern>/filter/*</url-pattern>
</filter-mapping>
<servlet>
<servlet-name>bar</servlet-name>
<servlet-class>com.MyServletAndFilter</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>bar</servlet-name>
<url-pattern>/servlet/*</url-pattern>
</servlet-mapping>
</web-app>
public class MyServletAndFilter extends HttpServlet implements Filter {
@Override
public void init(FilterConfig filterConfig) {}
@Override
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
doYourStuff((HttpServletRequest) request, (HttpServletResponse)
response);
}
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
doYourStuff(req, resp);
}
private void doYourStuff(HttpServletRequest req, HttpServletResponse
response) throws IOException {
response.setContentType("text/plain");
response.setStatus(400);
response.getWriter().println("TEEEEEST");
}
}
On Wed, Mar 9, 2011 at 4:36 PM, Ryan Stewart <rds6235_at_gmail.com> wrote:
> 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
>>>>>
>>>>>
>>>>
>>>
>>
>