tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Next release
Date Sun, 16 May 2004 18:58:07 GMT
Remy Maucherat wrote:

>> For the critical path probably it's good to keep using an interface, 
>> but for all "container changes" and other notification - there is no 
>> performance issue.
> Yes, but we can't be too bad either: if we take one minute to deploy a 
> webapp (unless we're precompiling on deploy ;) ) then it would be bad.

Not so bad IMO ( and we should precompile on deploy :-)

>> If you are going to touch the architecture - one thing I allways hated 
>> was using the same path ( "extension point" ) for all request 
>> processing. That was one of my fundamental problems with the valves. 
>> Keep the valves if you like them - but have separate chains for 
>> authentication, authorization, logging, etc. It not only cleans the 
>> code, but it also opens stuff for reuse.
> I still like the genericity actually, and since the pattern is still:
> 1) going in
> 2) invoke next (if you want to; if you don't processing stops)
> 2) going out
> JBoss does the same with its interceptors, and the API they used is the 
> same as the pre-TC 4 (ie, you get a pointer to the next interceptor).

I know, I can live with the recursive behavior.

The question is if we should keep one long chain including all types of 
modules in random order or have separate extension points.

Jboss interceptors can be applied on any operation ( AFAIK ) - you don't 
have a single chain for all operations.

The interface is still the same - and you could still put valves in
a single row if you want. But it may be helpfull if we would provide 
additional "extension points" where valves could be inserted. For 
example auth, logging, etc.

The benefit:
- you could reuse some extension points for other purposes - logging or 
auth, etc
- you may want to skip some chains for internal includes
- it may be cleaner
- we may get shorter stacktraces ( I know it's cosmetic :-)

It's just applying the Valve pattern in more places. Still same pattern 
like in jboss ( or even closer !), they use this for much more than a 
single chain.

"Extension point" is used in eclipse - it is a pretty good name :-)

> I don't quite see how "typed" valves would fit into this: instead the 
> chains are associated with the containers.

Yes, sort of a vertical chaining - you still have one long chain.

I'm talking about a horizontal chaining - the valves are not "typed", 
the same valve can be used in multiple chains ( or like in the current 
single long chain ). The extension points are not typed either ( i.e. no 
special java interface ).

> I plan to start working on this refactoring in a "catalina2" folder in 
> jakarta-tomcat-catalina (with an associated build script in 
> jakarta-tomcat-5), and I'll mark it as a proposal. I don't know what's 
> the chance of this making it in a full fledged release before the next 
> Servlet spec (athough it hasn't been started yet, so who knows when 
> it'll happen ...), so if there are benefits a new intemediate branch 
> will be needed. I assume we're not going to get rid of the current 
> servlet container impl, here.

It may be better to make those changes incrementally, in the main 
release area, if possible.

A lot of people haven't moved to tomcat5 yet.


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

View raw message