Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <40893BD6.90208@apache.org>
Date: Fri, 23 Apr 2004 18:52:54 +0300
From: Neeme Praks <neeme@apache.org>
User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040413)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: [logging] [proposal] Log.getChildLogger(String) method and managed
 environments
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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