Re: [VOTE] Branch j-t-c for Tomcat 5

2003-01-20 Thread Jeanfrancois Arcand
A little late :-)




[ ] +1 I Support the idea of a branch, and will help maintain it.
[X ] +0 I like the idea
[ ] -0 I don't like the idea
[ ] -1 I'm against the idea of branching

 


-- Jeanfrancois



 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE] Branch j-t-c for Tomcat 5

2003-01-18 Thread Glenn Nielsen
Glenn Nielsen wrote:

Bill Barker wrote:


I, personally, think that it's time for a branch in j-t-c.  At this 
point,
even Tomcat 3.3 won't build against the HEAD.

My proposal is:  Revert the JMX dependencies in j-t-c, Create a branch 
(e.g.
coyote_10), and re-apply the JMX patches to the HEAD branch.  Tomcat 
3.3 and
Tomcat 4.1 will use the coyote_10 branch, and Tomcat 5 will use the HEAD.


[ ] +1 I Support the idea of a branch, and will help maintain it.
[X] +0 I like the idea
[ ] -0 I don't like the idea
[ ] -1 I'm against the idea of branching





Ok, after some more explanation (Thanks Remy & Costin) I will change my vote to +0.

Glenn


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE] Branch j-t-c for Tomcat 5

2003-01-18 Thread Remy Maucherat
Glenn Nielsen wrote:

Why is it not possible to add (optional) JMX support to j-t-c components so
that we don't have to branch?

I did not say anything about 4.1, just that I feel it is preferable to not
have to maintain two j-t-c code bases.


You can't have everything JMX being optional, it would be just a big 
mess. Plus, for some changes, it's impossible.

I am a huge +1 on using JMX to capture runtime monitoring data,
but -1 on having two branches to maintain in j-t-c.




I think this is a majority vote. Besides, it was agreed on before that 
a branch would be created in j-t-c.


Please point me at the previous vote. If we voted and approved branching 
j-t-c
previously why wasn't it branched then and why are we voting again?

There was no vote, but it was mentioned in Costin's posts (or the 
replies), when talking about changing Coyote API to something JMX.

The added development overhead is small, and I feel it is needed to keep 
the 4.1.x tree stable.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



Re: [VOTE] Branch j-t-c for Tomcat 5

2003-01-18 Thread Costin Manolache
Glenn Nielsen wrote:

>>> Before branching and having to maintain patches in two branches,
>>> why not try to fix the builds and/or change the implemenation of the
>>> additional JMX support so that it can be built optionally.
>> 
>> 
>> Sorry, but this is not possible, and I will *not* include these changes
>> in 4.1.x, at least not for now.
> 
> Why is it not possible to add (optional) JMX support to j-t-c components
> so that we don't have to branch?

Because optional JMX is going to be too painfull and limit a lot of what 
we can do ( or make it much more complex than it needs to be ).

I'll remove JMX from util - that can be easily avoided. 3.3 and 4.0 
have their own http and ajp connectors.


> I did not say anything about 4.1, just that I feel it is preferable to not
> have to maintain two j-t-c code bases.

I agree - but if the cost is making the code too convoluted and use only a 
small subset of JMX - I think it's better to branch.

Registration can be wrapped ( easily ). Notifications and use of 
MBeanRegistration are hard to wrap. 

>From a different perspective - even if j-t-c is branched, it should be
possible to use either branch in any tomcat - if you have JMX, you can
use HEAD with 3.3 or 4.1. 

Costin







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE] Branch j-t-c for Tomcat 5

2003-01-18 Thread Glenn Nielsen
Remy Maucherat wrote:

Glenn Nielsen wrote:


Bill Barker wrote:



[ ] +1 I Support the idea of a branch, and will help maintain it.
[ ] +0 I like the idea
[ ] -0 I don't like the idea
[X] -1 I'm against the idea of branching




Before branching and having to maintain patches in two branches,
why not try to fix the builds and/or change the implemenation of the
additional JMX support so that it can be built optionally.



Sorry, but this is not possible, and I will *not* include these changes 
in 4.1.x, at least not for now.

Why is it not possible to add (optional) JMX support to j-t-c components so
that we don't have to branch?

I did not say anything about 4.1, just that I feel it is preferable to not
have to maintain two j-t-c code bases.




I am a huge +1 on using JMX to capture runtime monitoring data,
but -1 on having two branches to maintain in j-t-c.



I think this is a majority vote. Besides, it was agreed on before that a 
branch would be created in j-t-c.


Please point me at the previous vote. If we voted and approved branching j-t-c
previously why wasn't it branched then and why are we voting again?


Regards,

Glenn


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE] Branch j-t-c for Tomcat 5

2003-01-18 Thread Remy Maucherat
Glenn Nielsen wrote:

Bill Barker wrote:



[ ] +1 I Support the idea of a branch, and will help maintain it.
[ ] +0 I like the idea
[ ] -0 I don't like the idea
[X] -1 I'm against the idea of branching




Before branching and having to maintain patches in two branches,
why not try to fix the builds and/or change the implemenation of the
additional JMX support so that it can be built optionally.


Sorry, but this is not possible, and I will *not* include these changes 
in 4.1.x, at least not for now.

I am a huge +1 on using JMX to capture runtime monitoring data,
but -1 on having two branches to maintain in j-t-c.


I think this is a majority vote. Besides, it was agreed on before that a 
branch would be created in j-t-c.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



Re: [VOTE] Branch j-t-c for Tomcat 5

2003-01-18 Thread Glenn Nielsen
Bill Barker wrote:

I, personally, think that it's time for a branch in j-t-c.  At this point,
even Tomcat 3.3 won't build against the HEAD.

My proposal is:  Revert the JMX dependencies in j-t-c, Create a branch (e.g.
coyote_10), and re-apply the JMX patches to the HEAD branch.  Tomcat 3.3 and
Tomcat 4.1 will use the coyote_10 branch, and Tomcat 5 will use the HEAD.


[ ] +1 I Support the idea of a branch, and will help maintain it.
[ ] +0 I like the idea
[ ] -0 I don't like the idea
[X] -1 I'm against the idea of branching




Before branching and having to maintain patches in two branches,
why not try to fix the builds and/or change the implemenation of the
additional JMX support so that it can be built optionally.

I am a huge +1 on using JMX to capture runtime monitoring data,
but -1 on having two branches to maintain in j-t-c.

Glenn



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: [VOTE] Branch j-t-c for Tomcat 5

2003-01-18 Thread Remy Maucherat
Costin Manolache wrote:

Bill Barker wrote:



I, personally, think that it's time for a branch in j-t-c.  At this point,
even Tomcat 3.3 won't build against the HEAD.

My proposal is:  Revert the JMX dependencies in j-t-c, Create a branch
(e.g.
coyote_10), and re-apply the JMX patches to the HEAD branch.  Tomcat 3.3
and Tomcat 4.1 will use the coyote_10 branch, and Tomcat 5 will use the
HEAD.

[X] +1 I Support the idea of a branch, and will help maintain it.
[ ] +0 I like the idea
[ ] -0 I don't like the idea
[ ] -1 I'm against the idea of branching




We can branch at tomcat_4_19 tag - that's the simplest solution.

Sorry for the mess - but I think the benefits of knowing what happens
inside tomcat are worth the extra dependencies and some temporary build
problems ( and an extra branch ).


+1 for branching based on the TOMCAT_4_1_19 tag. That's what I was going 
to propose anyway.

Indeed, one of the biggest problems in Tomcat 4.1.x is there are no 
monitoring capabilities at all (except doing a thread dump, I guess ;-) ).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



Re: [VOTE] Branch j-t-c for Tomcat 5

2003-01-17 Thread Costin Manolache
Bill Barker wrote:

> I, personally, think that it's time for a branch in j-t-c.  At this point,
> even Tomcat 3.3 won't build against the HEAD.
> 
> My proposal is:  Revert the JMX dependencies in j-t-c, Create a branch
> (e.g.
> coyote_10), and re-apply the JMX patches to the HEAD branch.  Tomcat 3.3
> and Tomcat 4.1 will use the coyote_10 branch, and Tomcat 5 will use the
> HEAD.
> 
> [X] +1 I Support the idea of a branch, and will help maintain it.
> [ ] +0 I like the idea
> [ ] -0 I don't like the idea
> [ ] -1 I'm against the idea of branching
> 

We can branch at tomcat_4_19 tag - that's the simplest solution.

Sorry for the mess - but I think the benefits of knowing what happens
inside tomcat are worth the extra dependencies and some temporary build
problems ( and an extra branch ).

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




[VOTE] Branch j-t-c for Tomcat 5

2003-01-17 Thread Bill Barker
I, personally, think that it's time for a branch in j-t-c.  At this point,
even Tomcat 3.3 won't build against the HEAD.

My proposal is:  Revert the JMX dependencies in j-t-c, Create a branch (e.g.
coyote_10), and re-apply the JMX patches to the HEAD branch.  Tomcat 3.3 and
Tomcat 4.1 will use the coyote_10 branch, and Tomcat 5 will use the HEAD.


[ ] +1 I Support the idea of a branch, and will help maintain it.
[ ] +0 I like the idea
[ ] -0 I don't like the idea
[ ] -1 I'm against the idea of branching




--
To unsubscribe, e-mail:   
For additional commands, e-mail: