You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mike Anderson <MM...@novell.com> on 2001/09/10 16:48:33 UTC
Re: [VOTE] Removal of mod_jk for Apache 2.0 from
jakarta-tomcat for Tomcat 3.3
+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
>
>
>
Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat for Tomcat 3.3
Posted by Ryan Bloom <rb...@covalent.net>.
On Monday 10 September 2001 07:48, Mike Anderson wrote:
++1! I didn't even know it existed anyplace other than JTC. I have
been supplying patches recently for it too. Also, having duplicate
code anyplace is just a bad idea. I am on a crusade to remove all
duplicate code from every code-base throughout the world. <evil-laugh>
:-) Anyway, from a non-committer, but sometime contributer, get
rid of the duplicate code, please.
Ryan
> +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
--
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------