Costin Manolache wrote:
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 ...
Tricky indeed, but no - you need to hack web.xml if you want it to become a portable pre-compile webapp.
If it is done internally - we can put the extra config and classes in a private file.
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.
My point was that AOP or jboss interceptors can be applied in multiple points. I didn't say it's easy to configure or understand all of them :-)
For us - we only need 4-5 points and the config can be quite simple - just the list of valves for each chain. Most likely you won't need to change any code in the valves - just regroup them and add the extra config.
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)
As you know I would preffer iterative style, like in apache - but one line is ok too. Reducing the stacktraces is nice, but the real benefit is in better organizing things.
In 3.3 the biggest problem was the fact that the module was a bit rigid - and that resulted in ordering issues. If you have separated chains - it's much simpler ( and it really doesn't matter if it's iterative or recursive ).
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.
Maybe a 5.1 ? My only concern is that if changes start adding up, it is much harder to get people to upgrade and to support multiple versions. Having 5.x releases adding more features and with relatively small API breakages may be easier to swallow. Plus it will get stable quicker - if it gets into another 1 year cycle then again many people will have to stay with the stable branch ( since that's what they use/maintain)...
Don't know - I saw far too many painfull major changes. For example - each Ant version added few API/behavior changes, but I don't think it was perceived as a huge change.
Costin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
