On Thu, Jul 10, 2008 at 5:59 PM, Alberto A. Flores <[EMAIL PROTECTED]> wrote: > You are correct, the default is REQUEST (if no dispatcher is specified).
... > The spec clearly doesn't specify whether a forward or a response.redirect() > is used. This means that it is up to the container to decide how this is > implemented. Depending on your portability requirements, this may or may not > be an issue (Tomcat vs Weblogic, Resin, etc)... Hmm, the whole point of 'following the spec' as you put it and indeed as I see it is to avoid portability problems ... Translocatability ... that's a big 'Buzzword Bingo' word that I remember from my training days, or maybe that's something else, Anyway if moving to a different container might mean having to change something (anything?) because Struts2 breaks if you don't, might mean not using Struts2 ... which would be a shame because after years of avoiding frameworks because ... well just because I like rolling my own, I actually like some of the Struts2 features ... i18n is a breeze for example (this whole idea of binding form input fields to buisness component private attributes on the other hand is just plain NASTY). Anyway, I will struggle on and no doubt come to a conclusion eventually Thanks again for all the input on this lyallex > > > Lyallex wrote: >> >> 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] >> >> > > -- > > Alberto A. Flores > http://www.linkedin.com/in/aflores > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
