commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Herve Quiroz <herve.qui...@esil.univ-mrs.fr>
Subject Re: [logging] [proposal] Log.getChildLogger(String) method and managed environments
Date Mon, 26 Apr 2004 16:03:09 GMT
Neeme,

I thought I could share my thoughts on this subject, more as a user of
[logging] rather than a developper.

I've been using [logging] in many of my projects until recently when I
needed inversion of control stuff. I have since switched to Avalon
Framework Logger API.  Actually, it's the only part of the Avalon
Framework that I use and I would prefer to use [commons-logging] if
possible. Not because I don't like Avalon but rather because I prefer to
use dedicated "bricks" (such as the Jakarta Commons ones) instead of a
whole framework for just 3 classes (LogEnabled, Logger, Log4JLogger).

But then, I need LogEnabled for some projects so that means that I will
continue to use Avalon Framework Logger API if you just implement
getChildLog(). It's just too bad to have two distinct projects doing
almost the same thing. But the same goes for Avalon Framework Parameters
API and [configuration].

Herve

On Fri, Apr 23, 2004 at 06:52:54PM +0300, Neeme Praks wrote:
> Hi!
> 
> 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.
> 
> Background:
> 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?
> 
> Rgds,
> Neeme
> 
> [1] thread on velocity-dev:
> http://www.mail-archive.com/velocity-dev@jakarta.apache.org/thrd3.html#09507
> 
> [2] specific messages on velocity-dev:
> http://www.mail-archive.com/velocity-dev@jakarta.apache.org/msg09556.html
> http://www.mail-archive.com/velocity-dev@jakarta.apache.org/msg09561.html
> http://www.mail-archive.com/velocity-dev@jakarta.apache.org/msg09563.html
> 
> [3] avalon logger interface:
> http://avalon.apache.org/framework/api/org/apache/avalon/framework/logger/Logger.html

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