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 09:28:14 GMT
>> May be being the RI prevents major evolution/révolution ?
> Tomcat isn't the RI and hasn't been for some time.

Up to 2.5/2.1 ?

>> Tomcat Light is a good idea but only costin works on it.
> If you like the idea, help him out.

Why should we still get this kind of reply on Tomcat list ? ;-(

I won't speak for Costin but I didn't have such time to works on Tomcat.
And for such project we need full time people involved.

The idea is to attract a community on it and GSoC is a great opportunity.

>> Asf has a great server framework, mina, but it's not used by Tc.
> I'm not sure building Tomcat on top of another framework is a good idea. If you
> have a PoC that shows otherwise that would be very interesting.

Mina is also ASF and why not speak with the MINA team ?
May be they'll more than interesting working on such area.

>> Osgi is getting more and more adoption
> True.


>> and Eclipse or Felix select Jetty as their http implementation.
> Back to size / ease of embedding.
>> Maven has never been used as build system and 10 years after Tc is still
>> stick with ant.

> And what, exactly is wrong with Ant? It does the job we need it to do and it is
> far simpler to work with than Maven. This has been discussed before and the
> conclusion then was that the pain wasn't worth the gain. I don't see anything
> that has changed that.

That's a reccurent part of the problem on the tomcat-dev list.
Why should we change something working ?

Maven arguments exist and you just can't say, it works with ant why
changing anything ?

How many major projects in ASF (and elsewhere) switched to Maven ?
It will really help make Tomcat more modular, maven modules will split
the complexity in more parts.
And modules could became bundles easily via maven-felix-plugin.

>> No luck, we couldn't use the maven modules approach for tc. Modules
>> would have helped the transition to Bundle.
> We don't have to use Maven to build a more modular Tomcat.

May be but with a big build.xml instead of many small poms ?

>>>> 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 ;-(
> Better late than never.

>> 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.
> So start making contributions to take Tomcat in this direction.

I'll be happy to spent some personal time (not during my job time),
but there should be a real acceptance here.

Maven use :

I worked some times ago on a mavenised version of Tomcat.
As it required a different source structure, I moved all sources to a
new layout.

And to automatize it, you should use some ant script before so it's
clearly unfriendly (and unusual for maven developpers

Openess :

Did the Tomcat community want to share and use components ?

Mina could provide some components.
Felix could use Tomcat as it HTTP implementation instead of Jetty.


Did Tomcat 7 should use an OSGI core and use it dynamic bundles model
to load on demand module (a sort of on demand HTTPd modules) ?

The discussion is open and please don't just reply "make contributions".

Ideas are contributions, not just code.

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

View raw message