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>
Received-SPF: pass (asf.osuosl.org: domain of
 robertburrelldonkin@blueyonder.co.uk designates 195.188.213.9 as permitted
 sender)
Subject: Re: [logging] getChildLogger Patch submitted to bugzilla
	issue	#36062
From: robert burrell donkin <robertburrelldonkin@blueyonder.co.uk>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <4349700E.7050203@j-hohwiller.de>
References: <433DD35C.6040904@j-hohwiller.de>
	 <433DDDC7.3020800@j-hohwiller.de> <1128872310.5014.135.camel@knossos.elmet>
	 <4349700E.7050203@j-hohwiller.de>
Content-Type: text/plain
Date: Sun, 09 Oct 2005 22:05:52 +0100
Message-Id: <1128891952.5014.159.camel@knossos.elmet>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Sun, 2005-10-09 at 21:31 +0200, Joerg Hohwiller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> robert burrell donkin wrote:
> > On Sat, 2005-10-01 at 02:52 +0200, Joerg Hohwiller wrote:
> > 
> >>-----BEGIN PGP SIGNED MESSAGE-----
> >>Hash: SHA1
> >>
> >>Joerg Hohwiller wrote:
> >>
> >>>Hi there,
> >>>
> >>>it all works and all tests passed.
> >>>I submitted the full patch at
> >>>http://issues.apache.org/bugzilla/show_bug.cgi?id=36062
> >>>
> >>>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.

good

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org