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/[EMAIL PROTECTED]/thrd3.html#09507 > > [2] specific messages on velocity-dev: > http://www.mail-archive.com/[EMAIL PROTECTED]/msg09556.html > http://www.mail-archive.com/[EMAIL PROTECTED]/msg09561.html > http://www.mail-archive.com/[EMAIL PROTECTED]/msg09563.html > > [3] avalon logger interface: > http://avalon.apache.org/framework/api/org/apache/avalon/framework/logger/Logger.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
