struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Servlet Path & Path Info on Weblogic 8.1 vs. Struts
Date Tue, 23 Sep 2003 23:44:38 GMT
Jing Zhou wrote:

>Thanks for your confirmation. It does appear to be a bug in WebLogic 8.1.
>I programmed a filter to work around this problem and some other
>issues in Oracle OC4J 9.0.3. It works fine. But I discovered the following
>behavioral differences between different vendors:
>The filter is mapped to *.do and related to-be-forwarded or
>to-be-included JSP pages through two filter mapping elements
>in web.xml. The settings are common for all vendors' server.
>* On Tomcat 4.1.24 and Resin 2.1.10,  the filter is invoked when *.do
>   action is received. When Struts forwards to (or includes) a target JSP
>   page, the filter is skipped over.
That's the way it's supposed to be in Servlet 2.3, but the spec was not 
crystal clear here either.  In Servlet 2.4, an additional configuration 
setting was added to let you ask for filters to be applied on RD.include 
and RD.forward, and the language strengthened to indicate that the 
default (and theoretically backwards compatible) behavior is to *not* 
apply the filters on RD calls.

>* On WebLogic 8.1 and OC4J 9.0.3, the filter is invoked when *.do
>   action is received. When Struts forwards to (or includes) a target JSP
>   page, the filter is invoked again (with wrapped http request and
>   response in our case).
Sigh ... there's actually two different issues here.

* They should not be invoking the filters again (see above)

* They should not be wrapping the request/response (most likely being 
done by their
  implementations of RequestDispatcher)  See the last paragraph of 
Section 6.2.2
  in the Servlet 2.3 spec.

>* In particular, OC4J wraps our http request and response wrappers
>   using its own class
>   when it is invoking the filter on the target JSP pages.
It's possible you might be able to work around the wrapping bug by 
casting to HttpServletRequestWrapper and then walking up the wrapper 
chain by calling getRequest on it, then repeating until you get back to 
your own request wrapper class.

>I could not judge whose behavior is right or wrong. They are even
>(2 to 2 here).
That makes not the slightest bit of difference if the behavior in 
question is actually defined in the spec.

> From what I read in the Java Servlet Specification,
>I couldn't find, for example, the servlet containers should invoke
>the filter or not when using the request dispatcher to include and/or
>forward to a target servlet. Is this an ambiguity here? or both ways
>of implementation are allowed?
For filters, see (for example) Section 6.2.1, where it says (** is 
around my emphasis added):

    When the container *receives an incoming request*
    it takes the first filter instance in the list and calls
    its doFilter method ...

where one infers that "incoming request" means an incoming HTTP request, 
not a RequestDispatcher call.  This was made clearer in 2.4.

For wrapping, see Section 6.2.2, as mentioned above.

>About OC4J wrapping our wrappers, it seems to me it violates the
>Specification where it demands the same wrapper instances should
>be used, correct?
Exactly.  But it's probably an issue in the RD implementation, separate 
from the question of whether they should be invoking the filter again.

It's kinda sad ... both of these companies have representatives on the 
JSR-154 expert group (Servlet 2.4), and should have seen the discussions 
related to these two issues.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message