commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken.H...@ubsw.com
Subject RE: [LOGGING] ClassLoader Problems
Date Tue, 23 Apr 2002 09:50:10 GMT
Craig,

Just to clarify, you wrote a LogFactory impl, and put it in the shared lib dir (so all apps
can use the same instance)?. If so, how do you determine which app to rename the category
for? I can't think offhand of knowing a particular instance / Class instance is in a particular
app, since no context is passed back (unless there's something on the thread? Thread context
ClassLoader?).

Or are you putting the LogFactory per app? I don't see how this could work though..

Ken.

-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: 22 April 2002 19:12
To: Jakarta Commons Developers List
Subject: Re: [LOGGING] ClassLoader Problems




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>


Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.


--
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