Thanks Tim. I think I am persuaded that Tomcat is right and WLS7 is wrong.
Actually what clinched it for me was not the 2.3 spec, but the 2.4 spec. SRV.6.2.5 reads: "1. only when the request comes directly from the client. This is indicated by a <dispatcher> element with value REQUEST, or by the absence of any <dispatcher> elements." A 2.3 app copied into a 2.4 container would have no dispatcher element, and therefore should behave as it would now with Tomcat. WLS7 apps will behave differently when copied into a 2.4 container; I can't believe that is the behavior desired by the authors of the spec. Unfortunately I have just tested my "hello" app with WAS5 beta. It behaves the same way as WLS7 (the filter is invoked when I forward to "hello.jsp"). Therefore, I think I'll keep my filter implementation working the "wrong" way, so our app's behavior does not change when we move to WAS5 and WLS7. I guess this issue will go away when BEA and IBM release spec 2.4 versions of their products. The introduction of the "dispatcher" tag removes any ambiguity. Yes, I know some people think there was no ambiguity even in 2.3 :) > -----Original Message----- > From: Tim Funk [mailto:[EMAIL PROTECTED]] > Sent: Friday, September 27, 2002 1:41 PM > To: Tomcat Users List > Subject: Re: TC4 servlet filter behavior different from WLS7 > > > See section 6.1.1 of the Spec 2.3 > "When the container receives the incoming request, it takes the first > filter instance in the list and calls its doFilter() method, > passing in > the ServletRequest and ServletResponse, and a reference to the > FilterChain object it will use." > > Therefore filters are only valid for the incoming request. The filter > chain should NOT be invoked for a RequestDispatcher.forward(). > > Also see this email from Craig about this: > http://archives2.real-time.com/pipermail/tomcat-users/2002-Sep tember/078864.html > > > Rob Worsnop wrote: > > Er.. thanks for the response, but I understand precisely > why Tomcat does not > > trigger the filter. I was looking for clarification on > whether it is Tomcat > > or WebLogic that is not compliant with the spec (which I > *have* read, BTW). > > > > One of the reasons I want to know is that we are using > WAS4.x and WLS6.x, > > which do not include final spec filters. For this reason I > have written my > > own implementation of the spec. My implementation currently > behaves like > > WLS7, and I am wondering if I should change it. > > > > > >>-----Original Message----- > >>From: Shapira, Yoav [mailto:[EMAIL PROTECTED]] > >>Sent: Friday, September 27, 2002 12:49 PM > >>To: Tomcat Users List > >>Subject: RE: TC4 servlet filter behavior different from WLS7 > >> > >> > >>Hi, > >> > >> > >>>For example: > >>>I have a servlet "/hello", which forwards to "/hello.jsp". > >>>I have a filter that is mapped to "/hello.jsp". > >>>Accessing "/hello" in WebLogic will trigger the filter. > That doesn't > >> > >>happen > >> > >>>in Tomcat. > >> > >>It was my understanding that the tomcat behavior here is correct. > >> > >>This is because you have NOT defined a filter for the > /hello pattern. > >>You HAVE defined a filter for the /hellp.jsp pattern. Just > >>because the > >>servlet at /hello happens to forward to hello.jsp, which matches a > >>filter pattern, just mean requests to the servlet at /hello > should be > >>filtered. They don't match the filter pattern. > >> > >>I would refer to SRV.6.2.4, specifically: > >> > >> > >>>This requirement means that the container, when receiving > an incoming > >>>request: > >>> > >>>Identifies the target web resource according to the rules of > >> > >>SRV.11.2. > >> > >>>If there are filters matched by servlet name and the web > >> > >>resource has a > >> > >>>servlet-name, the container builds the chain of filters > >> > >>matching in the > >> > >>>order declared in the deployment descriptor. The last > filter in this > >> > >>chain >corresponds to the last servlet-name matching filter > and is the > >>filter that >invokes the target web resource. > >> > >>I hope I'm not wrong on this one ;) I'd be interested in the > >>resolution > >>of this question. > >> > >>Yoav Shapira > >>Millennium ChemInformatics > >> > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
