commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [LOGGING] ClassLoader Problems
Date Mon, 22 Apr 2002 18:12:01 GMT

On Mon, 22 Apr 2002, John McNally wrote:

> Date: Mon, 22 Apr 2002 10:58:16 -0700
> From: John McNally <>
> Reply-To: Jakarta Commons Developers List <>
> To: Jakarta Commons Developers List <>
> Subject: Re: [LOGGING] ClassLoader Problems
>   It does not seem that static factory methods like
> > Log.getLogger(String) or Category.getInstance(String) are the best way
> > to invoke logging within a component meant to be used within a larger
> > system.
> >
> I should say it might not be a bad way to invoke the logger, but
> hardcoding the String key to be the classname where the logger is used
> appears to be a bad choice.  A component needs to have a way to allow
> the system using the component to override the region/category.

"Good" versus "bad" is a pretty emotion-laden discussion starter :-)

I would point out, though, that the existing commons-logging
implementation lets you accomplish precisely the goal you specified,
without requiring a setLog() or equivalent method on the component itself.

As a test of this, I wrote a trivial LogFactory implementation whose
getInstance() methods simply renamed the one requested by the component to
match an application-specified hierarchy.  This works even if the
component itself thinks it is asking for a logger named after the
component class itself, with:

  private static Log log = LogFactory.getLog("");

This approach accomodates lots of other options -- from "make all the
components share a single Log implementation" up to very sophisticated
sharing approaches.

Personally, I find that this feature, coupled with the hierarchical
configuration supported by Log4J (I can set a default logging level for
"org.apache" to cover all my Apache-source components, and then override
it for just "")  makes a very flexible paradigm, without
imposing any requirements on the components themselves (except to document
what logger names they use :-).

> john mcnally


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

View raw message