On Oct 30, 2007, at 10:28 AM, Scott Ferguson wrote:

> On Oct 30, 2007, at 10:11 AM, Chris Chen wrote:
>> Scott,
>> Here's the document and the workaround that Confluence has been using
>> for quite some time:
>> http://confluence.atlassian.com/display/DOC/Known+Issues+for+Resin 
>> +3.x
>> Some of the configuration issues were likely due to the strictness of
>> Resin's validation.  The interesting one that I'm referring to is the
>> workaround for filter mappings as described in the doc where the
>> following
>> <dispatcher>REQUEST</dispatcher>
>> <dispatcher>FORWARD</dispatcher>
>> needed to be added to get things to work under Resin 3 whereas Tomcat
>> or others didn't seem to have this issue. I'm wondering what the
>> reason for this is and whether the servlet spec was simply up for
>> interpretation on that as was suggested by someone.
> The spec is pretty clear on that case.  A missing <dispatcher> means
> REQUEST only.
> There might be a case where Resin itself is calling forward() (e.g.
> for a login page?), when it should be treating the request as a top
> level request or calling sendRedirect.

I believe that's actually one of the cases people were having  
problems with.  I have seen some of the jira issues where people say  
that they were redirected to the login page for every page they  
request.  So they had to login again and again.  Some claim to have  
session timeout issues, which may possibly be caused by either the  
filters not getting the proper logged in values (getUser/Principal()  
methods returning null).


resin-interest mailing list

Reply via email to