commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Hohwiller <>
Subject [logging] getChildLogger and LogFactory(Impl)
Date Wed, 28 Sep 2005 20:16:13 GMT
Hash: SHA1

Hi there,

the current way to get an instance of "Log" is using the LogFactory
(getInstance(*) on the LogFactory instance). Actually this method
performs caching of the "Log" instances so when you request a "Log"
for the same name multiple times you will get the same instance as result.

A naive implementation of "getChildLogger" could simply
use LogFactory.getLog(String) to construct the child logger what might
cause confusion when the parent "Logger" instance was not created
via the factory. But currently there is no way to see if the
"Log" instance was created by the factory or not.

The other naive way is to directly create the child-logger instance
via the Logger's implementation own String constructor. This solution
would bypass the cache of the LogFactory.

I think that version 1. is inacceptable. Version 2. would be okay
but not elegant. The approach would underline that we will have two
different approaches of how to use commons-logging:
The current way where Log is enough
and the "IoC" way where some container/framework will create an
"initial" Logger and further loggers would be created via the
"getChildLogger" method and injected to components, that themselves may
create "child-child-loggers" via that method. The caching is not needed
in this world, because it would be a design/code error if a logger with
the same name is created multiple times.

As I said going with version 2. is okay. Anyways
I am still looking for the elegant solution 3. :)

What I want to do is:
Add a non-arg constructor to all Logger implementations that create the
root logger instance. This constructor would be the one used by the IoC
world (on suggestion via javadoc). Maybe I will store this information
in a flag so I can decided how to create the instance returned by the
"getChildLogger" method (e.g. choose between solution 1. or 2. according
to the flag and copy the flag to the child instance).
For the moment this is my solution 3. When I have a better idea I will
let you know or you may let me know of your ideas...

Further I was thinking that maybe even the other way round would be
better - so the facotry would explicitly set the flag. But this might be
tricky - for me it seems to be impossible without breaking compatibility
with existing Log instances or doing very wired stuff.

Additionally I will create an abstract implementation of the Logger
Interface and extend this in all implementations instead of implementing
the Interface (currently Log). This basic implementation can contain
general code to prevent redundancies (e.g. the logic how to build the
name of the child-logger). The (java)doc will tell NOT to directly
implement the Log or Logger interface but extend that AbstractLogger
class. This way we can easier add a new method to the Logger interface
because we can have a default implementation in the AbstractLogger class
for that method. So we do not break third-party code that we can not

Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


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

View raw message