commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: [logging] proposal
Date Wed, 03 Aug 2005 09:35:10 GMT
On Tue, 2005-08-02 at 23:02 +0200, joerg wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Simon Kitching wrote:
> > [AARGH - I hate top-posting!]
> mmh, whatever you may mean with that (I am not a native englishman)...

Top-posting is where someone replies to an email then puts their
comments *above* the stuff they are commenting on.

Bottom-posting is where the reply goes *below* the stuff being commented
on - as you did above, and I am doing now. It means that the email makes
sense when read from top to bottom.

The email I replied to was in the "top-posting" style so I continued
that, as mixing the two styles is *really* confusing. Actually, though,
I can live with either order as long as the contents of the email are
worth reading :-)

> > 
> > If you were to create a bugzilla entry with an implementation of this
> > feature and supporting unit tests [and assuming no-one else votes
> > against it] I will review and commit it sometime in the next few weeks.
> > 
> > Note, however, that commons-logging isn't making much progress at the
> > moment, and several issues standing in the way of a new release. So
> > there's no guarantee of when the next release might actually be pushed
> > out.
> Great! This sounds like an option.
> I wouldn't mind making the bugzilla entry and writing junit tests.
> Maybe the two Joergs (and whoever likes this proposal) may get together
> doing this.
> 
> Just let me know if I get it right:
> We add a new interface called Logger that extends Log.
> That is going to have two additional methods
> "String getName()"
> "Logger getChildLogger(String)"
> Is that right?

Hmm. Methods can't be added to the existing Log interface without
breaking all existing implementations of that interface, ie all logging
adapter code not part of the JCL project.

It would be possible to extend the existing interface as you indicate,
and update all of the logging adapter classes in JCL to implement this
extended interface. As long as all the APIs on LogFactory etc. still
deal in the old Log interface this won't break existing code that *uses*
JCL. And as long as the LogFactory/LogFactoryImpl classes always deal
with Log references, *not* the extended interface, JCL will still work
ok with existing log adapter classes that aren't part of JCL. However
code that wants to access the name info would need to cast the Log
object to the extended interface - and handle ClassCastException in the
case where the log adapter class actually implements only the old
interface and not the new one. That sounds ok to me - the number of
places where code wants to get a Log object's name isn't huge.

A slight variant of this is to create a new interface containing just
the new methods and make all existing log adapter classes implement this
new interface in addition to the current (unchanged) Log interface. I
can't currently see anything that makes this better or worse than the
above approach.

Or maybe LogFactoryImpl could have an extra method:
  LogFactoryImpl.getNameOfLog(Log l)
which iterates over the entries in the instances map looking for the
object and returning its name. This wouldn't be very fast but looking up
the name for a logger wouldn't be a common operation. I guess a
bidirectional map would help that. This would then allow any Log object
to have its name retrieved as long as the standard LogFactoryImpl is
being used. It would probably be clumsy to use though.

> You would also like me to send patches for the exisitng implementations
> so they implement Logger instead of Log?

> Further I leave things like LogFactory untouched. So whoever wants to
> have these two additional methods may cast from Log to Logger if he uses
> the LogFactory.
> Is that the right way to keep things easy and have no trouble with
> compatibility?


Well, I'm not wildly keen on the name "Logger"; it tends to imply
java.util.logging or log4j compatibility to me. But I don't currently
have a better suggestion. 

But generally, I think you're on the right track. You will need to think
carefully about the compatibility issues though; they are very
important.

> > PS: Two Joerg Schaibles? How confusing!
> > 
> > 
> My name is Jörg Hohwiller.

Ah. Sorry I misunderstood.

Cheers,

Simon



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