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.
By having a commons properties file that reads what the logging proxy class
is, I could then write my own proxy to be compatible with Expresso, and
then play nice with all the commons projects configuration-wise...
Is there a configuration option that I'm missing? [quite possibly :)]
Thanks,
-Mike
