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). -ck _______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
