commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [logging] To depend or not to depend?
Date Mon, 10 Feb 2003 15:52:25 GMT


On Mon, 10 Feb 2003, James Strachan wrote:

> Date: Mon, 10 Feb 2003 08:24:39 -0000
> From: James Strachan <james_strachan@yahoo.co.uk>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> Subject: Re: [logging] To depend or not to depend?
>
> From: "robert burrell donkin" <robertburrelldonkin@blueyonder.co.uk>
> > On Saturday, February 8, 2003, at 08:16 PM, Leo Simons wrote:
> >
> > > James Strachan wrote:
> > >> Would it be acceptable
> > >>> to add a getName() or something similar to the Log interface and the
> > >>> implementations? That way, we can fully implement the avalon-framework
> > >>> Logger contract on top of commons-logging.
> > >> +1.
> > >> Seems reasonable to me. I guess it won't break anyones code who just
> use
> > >> commons-logging to log. The only risk is people who implement Log,
> > >
> > > yep. It is a backwards-incompatible change there.
> >
> > losing backward compatibility seems to me like it might open up a whole
> > can of worms. i worry that here in the commons we'd be left with major
> > incompatible problems between components based on the version of
> > commons-logging that they used.
> >
> > a lot of time and debate was spent on the Log interface. as far as the
> > original idea is concerned, it's exactly right the way it is. once we
> > start changing the original concept, when do we stop?
> >
> > rather than dive in and make changes to something which took literally
> > months of debate to get right (ie the Log interface), i'd prefer it if we
> > could look around for a solution which would preserve backwards
> > compatibility for this critical interface.
> >
> > wouldn't it be better to either extend Log or create a Logger class which
> > implements Log but which has the extra method(s) that leo needs?
>
> I hear you - though this change would maintain backwards compatibility for
> people who use Log, it would just break Log implementations. I wonder how
> many people have developed custom Log implementations?
>

A lot more than you might expect.

Large scale applications that want to take advantage of the flexibility
inherent in the current design will often implement Log and LogFactory in
a glue layer to adapt libraries using commons-logging into an existing
architecture.

> Maybe we could introduce a seperate interface, NamedLog which has a single
> getName() method? Or just use introspection and add a getName() method to
> the core Log implementations? Though both of these increase the size and/or
> complexity of commons-logging, so I'd personally prefer just adding a new
> method to Log; its a fairly minor change.
>

NamedLog wouldn't help the stated Avalon use case, because there would
still be existing libraries that don't use it.  Convincing the world to
change would not be a likely scenario.

Adding a new method might be OK in a 2.x release (although I don't feel a
particular compulsion towards it), but would be against the spirit of
Commons support for backwards compatibility in a 1.x releaese; so I'd
definitely be -1 there.

> James

Craig

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