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 23:52:14 GMT
Remy Maucherat wrote:
> 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.


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

View raw message