----- Original Message -----
From: "Michael Rimov" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 15, 2001 7:25 PM
Subject: Re: Logging


> At 07:13 PM 8/15/2001 +0100, you wrote:
>
> >----- Original Message -----
> >From: "Morgan Delagrange" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Wednesday, August 15, 2001 7:03 PM
> >Subject: Re: Logging
> >
> >
> > > >
> > > > This cripples the features of log4j, you can't use
> > > > anything that makes log4j
> > > > an amazing tool. It's like cutting log4j off at the
> > > > knees.
> > > >
> > >
> > > Well I don't know about that.  The Logging component
> > > supports the debug, info, warn, error, fatal,
> > > isDebugEnabled, and isInfoEnabled methods of the Log4J
> > > Category class, plus anything you can configure from
> > > the log4j.properties file (which is a lot).  I
> > > wouldn't be surprised if most folks use exactly that
> > > subset of Log4J.
> > >
> > > That's why I'm much more interested in consensus than
> > > anything.  Both tools do a good job of standard
> > > logging.  I'd settle for either.
> > >
> >
> >Same for me *except* that the chosen solution need to be transparent if
the
> >log4j jar is not in the classpath ! ;-)
>
> I want to pipe in really quick here.  I added log4j into the Expresso
> framework some time ago, and when I did, I decided to go for the XML
> configuration capabilities.  Has paid off for our own apps as I can plug
in
> any xml file for any sub-webapp and my code picks it up.  However, it
> doesn't work too well when we add miscellaneous properties files for all
> the things like cactus, and that's where I'm concerned by having
everything
> in commons use log4j.

An idea :
Cactus should instanciate it's own instance of Log4j (not a JVM singleton)
so that it does not interfere with any other outside component. I don't know
if it is possible (Ceki ?). At the current time I use
"PropertyConfigurator.configure(url);".

[snip]
Thanks
-Vincent


Reply via email to