tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Gomez <>
Subject Re: [Proposal] Remove older of the two BIO AJP connectors
Date Thu, 02 Apr 2009 07:01:56 GMT

Le 30 mars 09 à 18:00, Mark Thomas <> a écrit :

> Henri Gomez wrote:
>>>> Ain't those used for 5.5?
>>>> You can however just remove them from the build.
>>>> Other option is to copy them to the 5.5 and not referencing
>>>> the connectors for those set of classes.
>>> Sorry - should have been clear. I only meant in Tomcat 7. I didn't  
>>> intend
>>> changing 5.5.x or 6.0.x
>> What's the state for Tomcat 7 ?
> Development is happening in trunk.
>> I wonder if they're allready some discussions/plans about it.
>> Not just technical/specs/RI plans but more generally what could/ 
>> should
>> Tomcat 7 be ?
> /trunk/TOMCAT-7-RELEASE-PLAN.txt
>> I could see that many projects (GWT/Eclipse), are now switching to
>> Jetty (which is great container also).
>> Did we miss something at some time ?
> Ease of embedding? Size?

Of course better embedding support, smallest (may be less jars), a  
faster start mode (with minimal features).

And also more openess to new commiters and external projects.

I still think that what make httpd success is it's modular approach  
with a well known internal request process.

Many modules raised outside core httpd team/project and some even  
joined it later.

And it get a bigger commiters community with new ideas and constant  

>> May be being the Servlet/JSP RI didn't allow too much 'revolution'.
> Have you read the 3.0 spec draft? There is a fair amount of change.  
> Whether it
> is good or not is a different question though.

I read it. It's a new spec. Dot.

May be being the RI prevents major evolution/révolution ?

Tomcat Light is a good idea but only costin works on it.

Asf has a great server framework, mina, but it's not used by Tc.

Osgi is getting more and more adoption and Eclipse or Felix select  
Jetty as their http implementation.

Maven has never been used as build system and 10 years after Tc is  
still stick with ant.

No luck, we couldn't use the maven modules approach for tc. Modules  
would have helped the transition to Bundle.

>> Probably it didn't help/allow new peoples join the project and add
>> some fresh air & ideas ?
> We could probably be more responsive / encouraging. I am trying to  
> get a couple
> of GSoC projects for Tomcat this year. Hopefully that will generate  
> something.

Good but may be too late ;-(

If i recall the tomcat story (10 years).

Code given by Sun to ASF. Tc 3.0 ?

Some ASF refactoring later came Tc 3.1 and then 3.2.

First 'fork', tc 3.3 - tc 4.0.

One project with individuals, the other with Sun commiters.

tc 4.1 and then 5.0 ended the fork.

But it became a Jboss commiters driven project.

5.5 and later 6.0 show the switch from Jboss to SpringSource  


Sun has it's own implementation, Grizzly.

Jboss forked tc code in it's own implémentation for AS.

Spring Source embed it in it's DM server.

Differents historicals leaders, differents commercial purposes/ 
requierements may explain why evolution/revolution has never been  
really well accepted ;(

That's why i wonder if tc 7.0 will just implements what 3.0  
requierements or will be a major evolution ?

My wishes for tc 7 and later :

A very small core for faster start and better embedded use.

Valves/filters/whatever should be just plugable modules. Here also  
OSGI / Felix / ServiceMixKernel have many good ideas to use.

Maven as a build system should be seriously reconsidered, modularity,  
artifacts depots, osgi support will be easier

Tomcat project should use and share components from others ASF  
projects,  Mina, Felix, ServiceMix, Commons have great stuff that  
could (should) be used. It will even be attractive for new commiters  
from these ASF project.

That's my wishes for Tomcat, not just code, bits and specs compliance,  
but recreate a new wider commiters/contributors community.

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

View raw message