commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [logging] getChildLogger Patch submitted to bugzilla issue #36062
Date Sun, 09 Oct 2005 21:05:52 GMT
On Sun, 2005-10-09 at 21:31 +0200, Joerg Hohwiller wrote:
> Hash: SHA1
> robert burrell donkin wrote:
> > On Sat, 2005-10-01 at 02:52 +0200, Joerg Hohwiller wrote:
> > 
> >>Hash: SHA1
> >>
> >>Joerg Hohwiller wrote:
> >>
> >>>Hi there,
> >>>
> >>>it all works and all tests passed.
> >>>I submitted the full patch at
> >>>
> >>>
> >>>Discussion is most welcome.
> >>
> >>First issue: I suggested to have non-arg constructors for each Logger
> >>implementation that create a "root-logger" (logger with empty name).
> >>This is not yet included (in the patch). I think this would be an
> >>additional issue towards IoC because the container could use that constructor
> >>instead of the LogFactory or the String constructor and from that point work
> >>with getChildLogger from the Logger interface without casting.
> > 
> > 
> > note that there are a few log implementations (in particular
> > AvalonLogger) which cannot logically support this. sounds like a
> > reasonable additional for those loggers which can logically support it.
> The loggers that can not logically support this (AvalonLogger, but what else?)
> are a bride to another meta-logger.

IIRC just avalon

> So the answer from the IoC point of view:
> A component requires a logger and for using the logger it is bound against
> a specific interface. The IoC container will provide a logger implementation for
> this interface and injects it into the component. It will make no sense to
> use another meta-logger as JCL implementation if you are in IoC and have the
> freedom of choice.
> If I understand it right, the only reason for such things as "AvalonLogger" are
> if you have Avanlon as IoC container but want to use a library in a
> avalon-component that wants to have a JCL logger.
> The AvalonLogger has to be statically initialized anyways to be used properly
> with JCL which is sick.

depends on the usage pattern. Log instances don't have to be created as
constants each class, it's just the most common idiom. for AvalonLogger
to be of much use, i'd say that the component would need to support
setting the Log instance on a per-class basis.

> So the short resumee: does not matter for me.


- robert

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

View raw message