commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
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 <jmcnally@collab.net>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> 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("my.class.name");

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 "org.apache.foo.bar")  makes a very flexible paradigm, without
imposing any requirements on the components themselves (except to document
what logger names they use :-).

> john mcnally

Craig


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


Mime
View raw message