tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: [Proposal] Remove older of the two BIO AJP connectors
Date Mon, 06 Apr 2009 22:18:18 GMT
On Mon, Apr 6, 2009 at 3:06 PM, Filip Hanik - Dev Lists

> Mladen Turk wrote:
>> Costin Manolache wrote:
>>> So in essence you have a new protocol but the sole
>>>> difference is how you describe it.
>>> The API can be something like:
>>> - legacyRequest(RequestMessage) - whatever we have in the current AJP
>>> protocol
>>> - getServerLoad() and whatever new we wanted to add
>>> Instead of defining AJP extensions, we just pick one of the marshalling
>>> libs
>>> and use them
>>> for encoding the new methods.
>> Again, you are presuming a new protocol and IMO everyone
>> here are just getting nasty red spots on their faces when
>> you do such a thing ;)
> I was gonna reply earlier, but my red spot reaction got kind of severe :)
> I have a hard time seeing why we would need yet another protocol.
> I think history has shown that to be a tough challenge.

I am saying the exact same thing - we shouldn't add another protocol, it was

a mistake to even have AJP proto in the first place, and we shouldn't
to extend it.

However we do need some form of communication between tomcat and jk -
what AJP provides won't allow much. And what I was suggesting is to not
do another protocol - but find an existing one and use/adapt it.


>> IMHO the solution would be to gather separate
>> community and move all development outside the
>> Tomcat, because it simply doesn't fit here.
>> The current code base for mod_jk and java side
>> connector is huge, and imagine how large it would
>> be with all the bells and whistles added.
>> Tomcat could serve as an incubator for such a
>> project, but I see no reason not to use
>> Apache Incubator directly. Maybe we will
>> attract larger community this way.
>> Regards
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message