commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Hohwiller <>
Subject Re: [logging] proposal
Date Wed, 03 Aug 2005 17:55:56 GMT
Hash: SHA1

Hi Simon,

Simon Kitching wrote:
> On Tue, 2005-08-02 at 23:02 +0200, joerg wrote:
>>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 :-)
Thanks for making this clear.
>>>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
>>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.
The casting thing is NOT nice but maybe that is not the problem because
you would only need to do this to get an initial logger
and maybe that binding could be done directly by a container framework
that directly instantiates the implementation class.
There would also be the opportunity to add a LoggerFactory that extends
LogFactory and add a "Logger createLogger(Class)" method or so but I
think this is NOT neccessary.
The people that are using JCL now should continue using it the way they
did before without any trouble of incompatibility even if they have
their own implementation of the Log interface!
But the ones who want to use JCL as a general API for logging that
allows interoperation of components from different projects
but can not see this happen without this additional method(s)
would be satisfied.
IoC Container guys might not really care too much about the LogFactory,
because this is what IoC and dependency injection is all about.
> 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.
So Logger would not extend Log?
For me this would be useless because the "Logger getChildLogger(String)"
method would not make any sense.
> 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.
Well I try to point out in a short run why people want the
"getChildLogger" method:
You write a component such as a persistence-layer. Therefore you write
a specification in form of an interface (or you use an existing spec. as
JDO) and you write an implementation. The idea of all these
Containerframeworks is that the implementation needs dependend
components like a logger that again have an API as specification and an
implementation. BUT the implementation should not worry about how to
get the implementation of the logger. It only uses the interface and
somehow magically the instance of that interface is injected from
outside by the container framework. Now the point is that the component
will -not surprisingly- create other objects, espc. those you might call
entities. Those are not components and they are not that smart in the
manner of the logic they contain BUT they might also need a logger.
And that is where wo go! Since they are not managed by the framework
but directly be managed by the component (our persistance layer in the
example) the persistence layer needs to supply the logger to them.
Now there are three ways how this can be done:
1. the same logger instance is given to the entity ->
the entity will write in the same log, have the same loglevel
and so on. That is often not acceptable.
2. the component has a dependency to the factory of the logger
(LogFactory). This is a way to go but would make it more complicated
for the component-writer. There are more disadvantages but we do not
want to make it too complicated.
3. the logger instance has a method to create a child logger.
The child logger will by default inherit the loglevel, have the
name of the parent logger as prefix of its own name and will by
default write to the same logfile. BUT -depending on the logger
implementation- the logger can be configured by its name.
So in an application there is only one logger implementation used
and the administrator knows the configuration syntax of that logger.

Our persistance layer and all its entities can run with the one logger
implementation in application A and with another in application B.
This is what already happens with JCL BUT:
Especially this can potentially happen with different container
framework implementations for A and B.

If you look at point 2. you can say the only reason for this is
lazyness. Well its also a bit more about design but however people are
lazy and on the other hand designers want to have a perfect world.

So you can see the need of getChildLogger(String) by these container
guys ot there here:


Please also note,%20java.lang.String)


So you see the need for the getChildLogger(String) method is definetly
If this really happens that we have the additional Logger interface you
can count on me that I will get on the mailing lists of all these
container guys and try to convince them to use
org.apache.commons.logging.Logger and kick out their own interface!

Now the more I think about it the more I like the idea that we are
currently heading towards:

Have the Log untouched and add the Logger that extends Log adding the
two methods.
There are other people that these container prayers (I am one of them)
and they will say hey a logger (Log) should only be able to log and not
also be a factory for loggers. For this reason there should be another
interface (LogFactory).

So hey we would please both worlds!!!

Further if one componets depends on Log and another depends on Logger
they still might work in the same container framework (as long as it is
not invasive as avalon is!).
>>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
> 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. 
I like it and not surprisingly all the container guys created their own
interface and called it Logger.
> 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.
The most important thing for me is to have that additional Logger
interface in org.apache.commons.logging. Adding a new interface will
surely not cause trouble. Now for me it would make sense if all
implementations of Log would then extend Logger and implement the new
methods. This will only break compatibility if someone is doing really
really really really really insane reflection stuff on the Log instance!
>>>PS: Two Joerg Schaibles? How confusing!
>>My name is Jörg Hohwiller.
> Ah. Sorry I misunderstood.
> Cheers,
> Simon
Take care
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


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

View raw message