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 :-)
My answer is yes but no, since we would have to hack the webapp's web.xml. I think it won't always work. Tricky issue ...
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.
Yes, I think it can be configured per EJB, but there's a big amount of XML to do that.
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'll think about it :)
(shorter stacktraces is a goal anyway, which is the idea of going back to pre-4.0 valves, where one valve invocation used one line instead of two right now)
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 think I do understand the concept now.
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.
5.0 should remain stable (right ?). There would be API breaking, big behavior changes, etc, so I don't see how it can happen in the same tree (but of course, it'll start off using the current code). If it can and if there isn't need for a proposal -> 5.0 branch, and break stuff (err, I mean work ;) ) in HEAD.
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
