No problem. It was an interesting exercise :)
On Wed, Mar 16, 2011 at 8:17 AM, Casper Bang <casper.bang_at_gmail.com> wrote:
> Thanks for testing Ryan. I am 99% my problem has to do with using
> EhCache's SimpleCachingHeadersPageCachingFilter, I've logged issues with
> Terracotta for this before (the filter not forwarding 3xx and 4xx response
> codes). I don't know why I didn't think of checking that at first, sorry to
> have wasted your time!
>
> /Casper
>
>
> On Wed, Mar 9, 2011 at 11:46 PM, Ryan Stewart <zzantozz_at_gmail.com> wrote:
>
>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>