commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [logging] detecting logging libs
Date Mon, 23 May 2005 21:34:45 GMT
On Mon, 2005-05-23 at 16:29 +1200, Simon Kitching wrote:
> On Sun, 2005-05-22 at 20:56 -0700, Brian Stansberry wrote:
> > --- Simon Kitching <skitching@apache.org> wrote:
> 
> > > I'd be happy with including this approach in the
> > > next release, removing
> > > the redundant isXYZAvailable methods and calling the
> > > next release 1.1.
> > > In practice, I'm sure no-one *does* subclass
> > > LogFactoryImpl so there's
> > > no problem.  In fact I'd be happier with this than a
> > > 1.0.5 where the
> > > methods exist but don't do anything.
> > >
> > 
> > +1
> 
> Ok. So questions:
>  * Robert are you ok with adopting Brian's approach to
>    checking a logger is ok (by creating one) rather than
>    using the current isXYZAvailable?

+1 (see comments previously)

>  * Robert, are you ok with ripping out the isXYZAvailable
>    methods and calling the next release 1.1?

breaking binary compatibility anywhere in JCL would be a very, very big
deal. JCL is used even more widely than commons-collections and breaking
binary compatibility would cause even greater misery. do you really want
to be responsible for breaking tens of thousands of applications world
wide...?

these changes would break symantic compatibility and so these are not
changes for a point release. a 1.1 release would be required as well as
appropriate notices in the release notes. i strongly believe that binary
compatibility in JCL needs to be preserved and therefore think that a
1.1 release containing improved discovery along these lines but
retaining the deprecated old methods would be the best approach.  

(as an aside: it is the presence of so many protected methods to allow
easy subclassing which is IMHO the main flaw in JCL. the algorithms
cannot be fixed without breaking compatibility.)

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message