commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neeme Praks <>
Subject [logging] [proposal] Log.getChildLogger(String) method and managed environments
Date Fri, 23 Apr 2004 15:52:54 GMT

For quite a long time I've had this proposal sitting on my TODO list, 
waiting to be put out in public. So, finally, here it is.

Some time ago on velocity-dev [1][2] (and on some earlier occasions) 
there has been brought up the unsuitability of commons-logging API for 
managed environments. This time I'll rant about the fact that the API is 
still 51% geared towards static factory approach and doesn't allow for 
more managed-environment-friendly approaches, like for example 
avalon-logging API [3].

    So, what is the issue? Let's take a scenario where we pass an 
instance of commons-logging Log class to a component that wants to log 
something. Ok, the component uses a strategy where it uses a supplied 
logger if there is something given to it by the "parent", otherwise it 
obtains a logger with from static factory. Fair enough. Current 
commons-logging API works for this use-case.
    What if we make our example more complicated (and realistic) and add 
to the picture several sub-components, used by the main component. How 
to solve this situation? Just use the same instance of Log and give it 
also to all the sub-components? If we would be satisfied with this, we 
could use the current "incarnation" of commons-logging.
    But what if we need to separate sub-component logging statements 
from each-other and from parent? (and this IS realistic) Then this 
approach falls apart and we need to use the static factory to obtain a 
new log instance. But now we lost our original aim of not using any 
static factories.

The solution? Introduce a new method to commons-logging Log interface:
    Log getChildLog(String logName);
Then all the components that need to hand a log instance to child 
components can use this method and if the underlying logging 
implementation supports it -- there will be no static-methods involved.

Background compatibility? In case the actual logging implementation does 
not support getting a child logger from a log instance, it can always 
delegate to the static factory (and the end result would be the same).

So, what do you think?


[1] thread on velocity-dev:

[2] specific messages on velocity-dev:

[3] avalon logger interface:

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

View raw message