tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <cost...@covalent.net>
Subject Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina Container.java
Date Fri, 09 Nov 2001 22:29:09 GMT
On Fri, 9 Nov 2001, Remy Maucherat wrote:

> > Well, Remy's commit seems ok - adding methods doesn't brake compatiblity.
> >
> > Removing methods ( or changing parameter types ) is a major problem, and
> > any connector module will be hurt.
> >
> > The important things is to decide ( ASAP ) if 4.1 is going to be backward
> > compatible with 4.0 or not.
>
> If yes means 100%, then the answer will probably be no. The page documenting
> 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 :-)

> > - 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 download
> 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. 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.

But that's nothing compared with the fact that none of this was discussed.
If nobody comments on a proposal it doesn't mean unanimous aproval, but
lack of interest - which is a good sign something is wrong.


Costin



--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message