Remy Maucherat wrote:
> Quoting Jon Stevens <[EMAIL PROTECTED]>:
>
> > on 1/19/01 11:51 AM, "Craig R. McClanahan"
> > <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Agreed ... I'm talking about the *Apache Tomcat* release cycle, where
> > we
> > > agreed in the release plan to have a feature freeze / bug fix round on
> > 4.0,
> > > and work towards a production quality release quickly. API surgery is
> > not
> > > something normally done late in a cycle like this. That is why it
> > needs to be
> > > discussed (and voted on, IMHO) before we change what was previously
> > agreed to
> > > on TOMCAT-DEV.
> >
> > I thought that this is what we are discussing right now. :-) I'm +1 on
> > doing
> > API surgery at this point...
>
> Ok, I've thought about the issue, and I don't really like the change from
> Valves to Filters, because I have the following concerns :
> - Valves are internal. They access internal objects. Making them filters will
> lead to more typecasting and more rtti.
As you will see from the proposal, I'm not suggesting we actually use filters.
In particular, the request and response objects passed to Valves are the internal
ones (org.apache.catalina.Request / org.apache.catalina.Response) to maintain
access to the internals.
As you note, Valves are for internal things and Filters are for application
things. The proposal is to make the two APIs structurally similar, but still
recognize the differences.
>
> - I'd like a clarification on how much response and request wrapping would
> occur. Basically, all internal filters should be able to mutate freely either
> the request object or the response object by typecasting the request and the
> response. I don't see anything preventing this if we're inside the servlet
> container (except what the servlet API says).
>
The arguments to Valve.invoke() are still the internal request and response
objects, just as they are today.
Although I didn't mention it earlier, the Filter API allows for wrapping request
and response objects (such as when a servlet uses them in a RequestDispatcher).
The current Valve implementation already supports wrapping in a very similar
manner, although in practice it will not be needed often - because a Valve can
mutate the request and response objects to some degree, while a Filter cannot.
You would still need to wrap the response, for example, if your Valve wanted to
modify the data content of the response (such as applying compression, or an XSLT
transformation). However, you should choose to implement functionality like this
as a Filter if you can, for maximum portability, and reserve Valve
implementations for implementing internal-to-Tomcat functionality.
>
> Do you think either of these is justified ?
>
> Remy
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
