+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
>>> [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 07, 2001 2:17 PM
> To: [EMAIL PROTECTED]
> 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
>
>
>
