You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Henri Gomez <he...@gmail.com> on 2009/04/02 09:01:56 UTC
Re: [Proposal] Remove older of the two BIO AJP connectors
Le 30 mars 09 à 18:00, Mark Thomas <ma...@apache.org> 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
évolution/révolution.
>> 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
'leadership'.
Today
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Posted by Henri Gomez <he...@gmail.com>.
>> It's disturbing that you fail to mention Geronimo altogether. If we can't
>> have cohesion within the ASF - you expect to create it externally?
>>
>
> I think that where Henri is going is that Tomcat has always been dependant
> on corporate sponsorship. First on Sun (who forked the code to GlassFish),
> then on JBoss (whom I understand from messages on the list has forked as
> well), and currently on SpringSource. Geronimo has historically considered
> Tomcat as a poor cousin ;), and preferred Jetty. Admittedly that has
> changed recently, and we're getting more patch submissions from Geronimo.
> But AFAIK, there are still no committers to both Tomcat and Geronimo.
Right Bill.
And I wonder why Geronimo, OSGI, Eclipse or GWT select Jetty ?
It's a good product but may be it's more attractive and open to newcomers ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Posted by Bill Barker <wb...@wilshire.com>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> wrote in message
news:49D55F2C.2030009@rowe-clan.net...
> Henri Gomez wrote:
>>
>> If i recall the tomcat story (10 years).
>> Today
>>
>> 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.
>
> It's disturbing that you fail to mention Geronimo altogether. If we can't
> have cohesion within the ASF - you expect to create it externally?
>
I think that where Henri is going is that Tomcat has always been dependant
on corporate sponsorship. First on Sun (who forked the code to GlassFish),
then on JBoss (whom I understand from messages on the list has forked as
well), and currently on SpringSource. Geronimo has historically considered
Tomcat as a poor cousin ;), and preferred Jetty. Admittedly that has
changed recently, and we're getting more patch submissions from Geronimo.
But AFAIK, there are still no committers to both Tomcat and Geronimo.
>> That's my wishes for Tomcat, not just code, bits and specs compliance,
>> but recreate a new wider commiters/contributors community.
>
> It takes outreach to make that happen. Mark isn't offbase, keep posting
> your wishes here, but if you want to make it happen, engage these other
> communities.
>
> The ASF isn't about being the only code solution. It's about
> collaboration
> to create what the active developers determine is the best solution. If
> anything is lacking in Tomcat, address it, and work with others to address
> it, but certainly don't spend your time wishing things were otherwise.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Posted by Mladen Turk <mt...@apache.org>.
Henri Gomez wrote:
>> I doubt you will get veto if this starts as module project
>> that can be used as drop-in component without changing the
>> overall API.
>>
>
> Under Tomcat umbrella we have now :
>
> - a Servlet container
>
> - an Apache/IIS connector (jk)
>
> - a native connector
>
> First guess, but I may be wrong, why not split in 3 projects ?
>
Don't think that's a smart way to move right now because
a) We simply don't have resources (community) for that.
However at least part of the native connector could in the
future go somewhere else (commons probably). I'm trying
to create one or two commons projects that would allow
more easier java/native integration, and if someone
creates a workable MINA based connector, native is
already in there.
JK is different, because we still don't know which
way to go in the future. If we came up with something
bright and shiny like JK3, and create enough community
we could ask for a TLP status and move the 1.2 native
code to that new project, leaving tomcat to what it
essentially is (servlet container)
Regards
--
^(TM)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Posted by Henri Gomez <he...@gmail.com>.
> I doubt you will get veto if this starts as module project
> that can be used as drop-in component without changing the
> overall API.
>
> The guys from MINA even use our tomcat native for high
> performance polling, so it's natural in a way to cooperate
> more closely.
>
> We can use two current BIO connectors as part of the core,
> and see how MINA can be used for async connectors.
> Since it supports both Java NIO and Tomcat Native, it's
> just cooperating with the guys and see what we would need
> to use it more effectively (and how at the first place :)
Thanks Mladen, happy to get a such positive feedback !
Under Tomcat umbrella we have now :
- a Servlet container
- an Apache/IIS connector (jk)
- a native connector
First guess, but I may be wrong, why not split in 3 projects ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Posted by Mladen Turk <mt...@apache.org>.
Henri Gomez wrote:
>
>>> That's my wishes for Tomcat, not just code, bits and specs compliance,
>>> but recreate a new wider commiters/contributors community.
>> It takes outreach to make that happen. Mark isn't offbase, keep posting
>> your wishes here, but if you want to make it happen, engage these other
>> communities.
>
> I could engage but there should be an acceptance here.
> I couldn't attract Mina/Felix people and got a veto here, it will be
> unfair and unproductive for other commuties.
> I call for openess and if it receive a positive feedback here, we
> could next contact others ASF projects.
>
I doubt you will get veto if this starts as module project
that can be used as drop-in component without changing the
overall API.
The guys from MINA even use our tomcat native for high
performance polling, so it's natural in a way to cooperate
more closely.
We can use two current BIO connectors as part of the core,
and see how MINA can be used for async connectors.
Since it supports both Java NIO and Tomcat Native, it's
just cooperating with the guys and see what we would need
to use it more effectively (and how at the first place :)
Regards
--
^(TM)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Posted by Henri Gomez <he...@gmail.com>.
> It's disturbing that you fail to mention Geronimo altogether. If we can't
> have cohesion within the ASF - you expect to create it externally?
It wasn't a list of J2EE engine but a list of applications/corps who
drive Tomcat life.
And Geronimo didn't take/fork/guide Tomcat isn't it ? :)
>> That's my wishes for Tomcat, not just code, bits and specs compliance,
>> but recreate a new wider commiters/contributors community.
>
> It takes outreach to make that happen. Mark isn't offbase, keep posting
> your wishes here, but if you want to make it happen, engage these other
> communities.
I could engage but there should be an acceptance here.
I couldn't attract Mina/Felix people and got a veto here, it will be
unfair and unproductive for other commuties.
I call for openess and if it receive a positive feedback here, we
could next contact others ASF projects.
> The ASF isn't about being the only code solution. It's about collaboration
> to create what the active developers determine is the best solution. If
> anything is lacking in Tomcat, address it, and work with others to address
> it, but certainly don't spend your time wishing things were otherwise.
Yes ASF is not the only solution, but with the rich apis/tools/peoples
in various ASF projects, it seems to me more elegant and pragmatic to
involve ASFers.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Henri Gomez wrote:
>
> If i recall the tomcat story (10 years).
> Today
>
> 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.
It's disturbing that you fail to mention Geronimo altogether. If we can't
have cohesion within the ASF - you expect to create it externally?
> That's my wishes for Tomcat, not just code, bits and specs compliance,
> but recreate a new wider commiters/contributors community.
It takes outreach to make that happen. Mark isn't offbase, keep posting
your wishes here, but if you want to make it happen, engage these other
communities.
The ASF isn't about being the only code solution. It's about collaboration
to create what the active developers determine is the best solution. If
anything is lacking in Tomcat, address it, and work with others to address
it, but certainly don't spend your time wishing things were otherwise.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Posted by Mladen Turk <mt...@apache.org>.
Mark Thomas wrote:
>
>>>> 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.
> Again, if *you* want to pursue this / think this is a good idea - *you* need to
> invest the time to pursue this / persuade others that it is worth them pursuing.
>
The problem with any framework is that with all the benefits
you pay the price. One is that it contain things you will absolutely
never need or use, and the second is that you depend on the
framework, so anything you need to add or fix its other community
dependent. Unless at least three of us become the mina's pmc members
that can push for a release, we would put ourself is the
'plug and pray' situation. However that doesn't prevent anyone
with extra time and will to create the mina based connector,
but of course as a separate module not part of the core.
In time this would eventually lead to satisfying the first requirement,
and eventually use it as core component.
IMHO we had a good example in http-client, where two
communities even under ASF umbrella simply couldn't
cooperate. The guys from http commons simply choose to take a blank
sheet of paper and completely break the backward compatibility,
leaving us sticked to version 3. Of course we could use version
4 (it was beta for how long, two years or more) since now
released, but who can assure us version 4.1 won't make
all our work obsolete again.
And, regarding maven, I absolutely agree with Mark.
There is nothing wrong with ant, and really see no reason
why would the switch be needed.
Regards
--
^(TM)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Posted by Mark Thomas <ma...@apache.org>.
Henri Gomez wrote:
>>> 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 ? ;-(
Because you are criticizing the direction things are going but making little to
no contribution to moving Tomcat forward in the direction you think it should be
going.
> The idea is to attract a community on it and GSoC is a great opportunity.
+1. Any help/advice you want to give to the prospective students would be very
much appreciated as they as their questions on the dev list.
>>> 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.
Again, if *you* want to pursue this / think this is a good idea - *you* need to
invest the time to pursue this / persuade others that it is worth them pursuing.
>>> 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 ?
Exactly. If it ain't broke don't fix it. There is always scope to do things
better but the reward has to be worth the effort required. That case has yet to
be made (in my view) for switching to Maven.
> Maven arguments exist and you just can't say, it works with ant why
> changing anything ?
They do but the last time someone tried to make them, the argument wasn't
compelling.
> How many major projects in ASF (and elsewhere) switched to Maven ?
No idea.
> 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 ?
Which is fine by me right now.
If there was a compelling argument to switch to Maven and go through the
associated learning curve I would be +1 for the switch. I have yet to see a
compelling argument.
>>> 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),
Great.
> but there should be a real acceptance here.
You need to make the case for each of these changes. If there is a case then I
for one would be +1.
> 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
> conventions/standardization)
As I said above, I don't see that the pain is worth the gain. I'm happy to be
convinced otherwise.
> 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.
I'm all for code re-use where we can. That is one of the reasons I am working on
the Commons components that Tomcat uses.
Any re-use is always going to be a trade off. Each case will need to be looked
at on it's merits but where it makes sense to do so it will get a +1 from me.
> OSGI :
>
> 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) ?
That is an awfully big step from where we are now. How do you propose we get
from where we are to a set of bundles running on an OSGI framework?
> The discussion is open and please don't just reply "make contributions".
>
> Ideas are contributions, not just code.
+1 but without contributions the ideas are unlikely to get anywhere
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Posted by Henri Gomez <he...@gmail.com>.
>> 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.
Indeed
>> 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
conventions/standardization)
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.
...
OSGI :
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Posted by Mark Thomas <ma...@apache.org>.
Henri Gomez wrote:
>>> 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 isn't the RI and hasn't been for some time.
> Tomcat Light is a good idea but only costin works on it.
If you like the idea, help him out.
> 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.
> 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.
> 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.
>>> 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org