If we were to go down the route of having a small & simple loggging
abstraction in commons then why don't we take the most common subset of
log4j that most people use (i.e the Category class) and provide a default
implementation that just logs to System.out.
This is pretty much what Morgan has done already - apart from I'm suggesting
we use the org.apache.log4j.Category class name for this and ensure that the
class is API compatible (providing a direct subset).
With the current logging proposal, to use any of the commons components
which depend on logging you need to add commons-logging.jar to your
CLASSPATH. If the commons-logging.jar was API compatible with log4j then
log4j users could use log4j.jar *instead* of commons-logging.jar - then they
would get the 'full monty', they wouldn't need to add an extra
commons-logging.jar to their CLASSPATH and there would be no wrapping of
log4j.
So the result would be
* a very small logging abstraction in commons, 1-2K in size.
* easy way for people to upgrade to full log4j - just swap
commons-logging.jar for log4j.jar
* easy way to adapt to other loggers (LogKit, JDK1.4 et al) since we're only
using the Category class.
* we only now have one logging API - log4j's Category - rather than 2.
James
----- Original Message -----
From: "Vincent Massol" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, August 16, 2001 9:13 AM
Subject: Re: [VOTE] Promote "Logging" Proposal to jakarta-commons
> +0
>
> * I prefer to leave the choice of how to do logging or not to each
> component. What we should mandate, is that each component logging system
> need not impact on the logging system used by an end-user. In my opinion,
> users of a component would like to turn logs on sometimes to check what's
> going on but they won't want to mix these logs with their own logs (at
least
> in most cases). The only issue I can see is each component will need to
> provide its own logging configuration and especially the output file path
> (which I set in Cactus to be the current directory).
>
> Question for Ceki: Is it possible to have several instances of Log4J (not
a
> JVM singleton), so that it does not interfere with any other outside
> component. At the current time I use
"PropertyConfigurator.configure(url);"
> which interferes.
>
> * I would be +1 for a commons logging component that you would use by
> copying the source into each other component source tree *and* change the
> package names .... :-) (a template)
>
> * My opinion is based on the experience with Cactus. It is just too hard
for
> end users to set up their classpath correctly (I'm already struggling to
> find solution for this) and whenever we add a new dependency it gets worse
> (check the attached diagram). For the moment, I like very much the
solution
> we have for Log4j (a wrapper in the same style as the logging component
that
> default to noop if log4j is not on the classpath).
>
> -Vincent
>
> ----- Original Message -----
> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, August 15, 2001 11:17 PM
> Subject: [VOTE] Promote "Logging" Proposal to jakarta-commons
>
>
> > This proposal is to move the "logging" package that is currently in
> > "jakarta-commons-sandbox" into "jakarta-commons" so that Commons package
> > users may utilize it in their packages.
> >
> > For those of you who haven't looked at it yet, this contains:
> > * A very thin Log interface, based on org.apache.log4j.Category
> > * Optional ability to declare your own integration layer
> > (implementation of Log) through system property settings
> > * Optional simple implementation that writes to System.out.
> > * Automatic use of Log4J if these classes are present in the
> > class path.
> > * Graceful degredation to swallowing log output silently if
> > no specific implementation is specified, *and* Log4J is
> > not available.
> >
> > Votes please?
> >
> > Craig
> >
> >
> >
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
