OK, I think I've twigged this now Every jsp page has this include
<jsp:include page="header.jsp"></jsp:include> recently I have included this in header.jsp (I'm messing around with Struts2 i18n) <%@ taglib prefix="s" uri= "/struts-tags" %> ... <span class='header'><s:text name="header.welcome"/></span> If I go back to this config in web.xml .. <filter-mapping> <filter-name>struts2</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> ... <welcome-file-list> <welcome-file>/welcome.jsp</welcome-file> </welcome-file-list> ... when I access the site the welcome page with it's included header loads fine. So obviously the request is going through the filter. If I then click the login link it all goes horribly wrong. looking at the exception trace it appears that login.jsp which also loads the header is where the problem lies So, it appears that there is a forward going on (or at least a redirect) somewhere when Tomcat sees that I am trying to access a protected resource This makes sense as I'm trying to access a servlet (Login) but I actually get a jsp (login.jsp) according to http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd another valid value for <dispatcher> is INCLUDE so I tried this on it's own ... boom, it all went wrong, so it looks like the default behaviour for the filter mapping thing is REQUEST. If you add any dispatcher then that seems to override the default config. Distressingly (perhaps) <filter-mapping> <filter-name>struts2</filter-name> <url-pattern>/*</url-pattern> <dispatcher>REQUEST</dispatcher> <dispatcher>INCLUDE</dispatcher> </filter-mapping> Doesn't do it, it has to be <filter-mapping> <filter-name>struts2</filter-name> <url-pattern>/*</url-pattern> <dispatcher>REQUEST</dispatcher> <dispatcher>FORWARD</dispatcher> </filter-mapping> phew, got there in the end I'm still not entirely convinced I've got to the bottom of things as I'm sure I had this working with the tags in the header but without the <dispatcher> stuff ... then again it's been a long week and I'm probably mistaken. Anyway, whoever said there was a forward going on ... take a bow, you were right and I was talking tosh If it's true that this fix does indeed break in some versions of IE then we are in a spot of bother with this. Thanks for the input, it got me thinking. Rgds lyallex On Thu, Jul 10, 2008 at 11:11 AM, Lyallex <[EMAIL PROTECTED]> wrote: > Hello > > Tomcat version 5.5.26 > Struts2 version 2.0.11.1 > > I'm trying to understand why, given the following in web.xml requests > sometimes 'miss out' the Struts2 filter > > <filter> > <filter-name>struts2</filter-name> > <filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class> > </filter> > > <filter-mapping> > <filter-name>struts2</filter-name> > <url-pattern>/*</url-pattern> > </filter-mapping> > > > It appears to really only be an issue with web.xml declarative security > > Reading around the various archives it appears that this is a know issue > when trying to use Struts2 Actions as the target but I'm not trying to do that > I just use a standard jsp. > > <odd> > > The really odd thing is that the login process works perfectly > sometimes and sometimes it fails with the (apparently well known) message > > The Struts dispatcher cannot be found. > This is usually caused by using Struts tags without the associated filter ... > > </odd> > > Here's the login config > > <login-config> > <auth-method>FORM</auth-method> > <realm-name>Form based authentication</realm-name> > <form-login-config> > <form-login-page>/login.jsp</form-login-page> > <form-error-page>/login.jsp</form-error-page> > </form-login-config> > </login-config> > > Someone, somwhere on my journey through the archives suggested this fix. > > <filter-mapping> > <filter-name>struts2</filter-name> > <url-pattern>/*</url-pattern> > <dispatcher>REQUEST</dispatcher> > <dispatcher>FORWARD</dispatcher> > </filter-mapping> > > It does appear to solve the problem I was just wondering why ? > > Is there a definitive resolution to this problem out there somewhere ? > > TIA > > lyallex > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
