tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <>
Subject Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina
Date Fri, 09 Nov 2001 22:58:56 GMT
> On Fri, 9 Nov 2001, Remy Maucherat wrote:
> > > Well, Remy's commit seems ok - adding methods doesn't brake
> > >
> > > Removing methods ( or changing parameter types ) is a major problem,
> > > any connector module will be hurt.
> > >
> > > The important things is to decide ( ASAP ) if 4.1 is going to be
> > > compatible with 4.0 or not.
> >
> > If yes means 100%, then the answer will probably be no. The page
> > the changes will also explain how to fix the affected components.
> The problem is that ( AFAIK ) it is not possible to 'fix' any component to
> deal with incompatible API changes.
> Adding methods is not the issue here - I have no problem with your current
> commits, that's easy to resolve.
> The problem is SocketFactory - if you know any way to fix jk or webapp to
> compile and work with both 4.1 and 4.0 ( which is what 'backward
> compatibility' should provide ) - please let me know :-)

Hey, you're the one who screamed that the API was totally broken because of
I suggest we do what we always do: create a branch for 4.0.

> > > - I assumed that if nobody comments or vote on a proposal that
> > > means 'no interest' - that's why 3 +1 votes are supposed to be needed.
> > > ( that's unrelated - I sent a -1 on management API beeing commited
> > > without discussion and vote - but nobody seemed to care, and that was
> > interpreted
> > > as ok to move ahead)
> >
> > I think it was addressed: the components are optional, and the JMX
> > and redistribution is now possible without selling your soul to Sun.
> This was not the point - the problem is that adding new components to the
> project should be the result of the vote, and the design and
> technology used must be agreed upon on tomcat-dev.
> The problem was not JMX - if you read my previous mail I'm perfectly happy
> with JMX support ( as long as it's optional ), but I'm not happy with a
> complex soap/struts/whatever app, that is supposed to use the abstraction
> of JMX but yet is specific to tomcat.

Yes, but Craig said that he didn't have time to do that. Which is
If Craig wants to develop something that adds some useful functionality, and
that he does it, I don't see how you can veto it. You can do something
better, and then call for a vote to throw out Craig's inferior solution.

I'm interested by the functionality you proposed, BTW.

> And the other problem was adding
> complexity to the project - Apache httpd doesn't include a complex
> management app in it's CVS, neither mod_perl.

So what ?
It's modular and independent, and having multiple repositories just makes
the thing harder to build.

> But that's nothing compared with the fact that none of this was discussed.

I think he did post quite a few proposals on the subject (and they were
ignored - ie, silently approved).

> If nobody comments on a proposal it doesn't mean unanimous aproval, but
> lack of interest - which is a good sign something is wrong.

That's not what the rules say. You're supposed to give your opinion when
asked to do so, or lose possibility to do so in the future (otherwise,
nothing gets done).


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

View raw message