tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Anderson" <MMAND...@novell.com>
Subject Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat for Tomcat 3.3
Date Mon, 10 Sep 2001 14:48:33 GMT
+1

JTC is the best place for this since it can be kept up to date
with an appropriate version of APR and Apache 2.0.

Mike Anderson

>>> Larry.Isaacs@sas.com 09/07/01 12:44PM >>>
I agree with Costin's suggestion to remove the Apache 2.0
version of mod_jk from jakarta-tomcat for Tomcat 3.3.
This would occur after any bug fixes missing from
jakarta-tomcat-connectors were ported.

It makes much more sense to have it live only in
jakarta-tomcat-connectors where it can quickly respond
to changes. I don't plan much maintenance on the connectors
once Tomcat 3.3 is released.

VOTE:

[ ] +1 REMOVE: Apache 2.0 mod_jk should be removed from
       jakarta-tomcat for Tomcat 3.3
[ ] -1 KEEP: Apache 2.0 mod_jk should be kept in
       jakarta-tomcat for Tomcat 3.3

My vote is +1.

Cheers,
Larry 

> -----Original Message-----
> From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com] 
> Sent: Friday, September 07, 2001 2:17 PM
> To: tomcat-dev@jakarta.apache.org 
> Subject: RE: cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0
> mod_w ebapp.c
> 
> 
> On Fri, 7 Sep 2001, GOMEZ Henri wrote:
> 
> > Don't forget that many of us must evaluate
> > a KNOWN Apache 2.0 in real environnement.
> > The most known are Apache sites which use the released
> > version 2.0.24 :)
> >
> > We could do that a each release (2.0.24/2.0.25) but
> > not in real-time ;)
> 
> Probably the correct solution is somewhere in the middle. I agree with
> Henri that using the HEAD is extremely difficult for both 
> developers and
> potential users who want to help testing or just evaluate 
> 2.0+jk. However
> sticking with an old snapshot and not testing with the HEAD 
> is also bad.
> 
> Having more frequent 'stable' snapshots of 2.0 would be IMHO the best
> solution, and keeping jk in sync with the latest snapshot 
> wouldn't be that
> difficult. At least we could get reproductible behavior - and more
> determinism.
> 
> So my proposal for jk would be to use snapshots - regardless 
> of alpha or
> beta status. When the dust settles on a 2.0 change and a new 
> alpha/beta
> snapshot is released - we can update our APIs.
> 
> BTW, giving the amount of change in 2.0 - what about removing 
> the 2.0 jk
> connector from 3.3, and relying on j-t-c for a 2.0 connector ?
> 
> Right now the jk code in jakarta-tomcat is supposed to be 
> 'stable', and
> only clear bug fixes are ported back. The 2.0 module can't be 
> considered
> stable ( since it changes all the time ) - and what could be 
> released with
> 3.3 will be certainly out of sync the next day.
> 
> Should we call a vote on this ?
> 
> Costin
> 
> 
> 


Mime
View raw message