Does anyone know if it true that if the Struts FilterDispatcher finds a
match for an action that the matching servlet is not invoked? That is,
will it will skip calling chain.doFilter(...) on the FilterChain object
when it finds a match? I have not looked at the source code yet.
Danny Hurlburt wrote:
Hello,
I am using Tomcat 5.5 as my servlet container. I have added the
org.apache.struts2.dispatcher.FilterDispatcher as a filter with
a url pattern of /*.
<filter>
<filter-name>struts2</filter-name>
<filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class>
</filter>
When following the HelloWorld example on the Strut's wiki
(http://struts.apache.org/2.x/docs/hello-world.html) I
could not get the filter to run. I set a break point in
the doFilter method. Then I would call
http://localhost:8080/cntxPath/HelloWorld.action
but the filter is never invoked. The filter is however
invoked if I request
http://localhost:8080/cntxPath/HelloWorld.jsp since
this request maps to the JSP servlet (but of course
the filter won't invoke an action class and will
simply let the JSP servlet write to the response).
The problem seems to be that since I don't have any
servlet mappings that will match
http://localhost:8080/cntxPath/HelloWorld.action the
filter is never invoked.
I don't have Tomcat's "default" servlet (which is mapped
to /) enabled. However when I do enable this, the request
http://localhost:8080/cntxPath/HelloWorld.action causes
the filter to be invoked an it attempts to find an
action mapping to HelloWorld.
I have read the Servlet 2.4 spec and it sounds like
filters will only be called if the URI matches some servlet
mapping AND the URI matches the filter mapping. Since I
don't have a servlet that would get invoked using
http://localhost:8080/cntxPath/HelloWorld.action the
Struts filter never gets invoked (unless I enable Tomcat's
default servlet which I don't want to do). It sounds like
Tomcat is doing what it suppose to do by not invoking the
Struts filter because there are no servlets matching any
servlet mappings.
I believe I can solve this problem with a No-op servlet
mapped to /*. This would be similar to enabling Tomcat's
default servlet.
Has anybody else ran into this problem? Anybody have any
solutions?
Thanks,
Dan
---------------------------------------------------------------------
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]
