----- Original Message -----
From: "James Strachan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 01, 2001 11:18 AM
Subject: Re: LOG4J
> > >Log4j is such a difficult package to use.
> >
> > 2 for 2. Ask youself why most projects that use log4j, use it behind a
> > fascade. Wrapping it behind a fascade goes against the use case that
> > everyone uses (see libc on most platforms and they have some sort of
> syslog
> > or ntlog style functionality). What would be your answer to this?
>
> I just had a quick look at the JSR and it looks like the package is going
to
> be java.util.logging (rather than javax.logging) so that rules out using
the
> JSR until you're sure all your users have moved to Merlin JDK 1.4 :-(
>
> So how about we add a simple, lightweight facade component for logging to
> jakarta-commons?
>
> Somewhere between 1 and 4 classes would probably do. Nothing fancy or too
> clever, just an easy to use, abstract Facade which is fairly similar to a
> subset of the JSR functionality. Probably include a simple simple
> implementation that just logs to a file or System.out that is used by
> default if no other implementation is configured. So simple, small and
> lightweight. Ideal for any project no matter how small (assuming some
> logging facility is required ;-)
>
> Then bindings to the JSR implementation, logj4 and possibly logkit could
be
> done and plugged in. If a project wants a more powerful logging mechanism
> they can plugin, say, log4j or logkit or the JSR.
>
> Something along the lines of a subset of the JSR would be quite easy to do
> in a small number of simple classes:-
>
The problem is that you have 2 choices. Either you abstract the full logging
API (including Formatting of messages, Categories, Appenders, Configuration,
...) and then you're fine but you do the same heavy work as the JSR is doing
or you only abstract a few APIs like log.debug(), log.warning(), ... but
then you're stuck if you wish to use the Categories of Log4j for example ...
You'll then have to use Log4j directly without going through your
abstraction classes because you need some special initialization, the
methods do not have the same needed input parameters, ...
I would prefer to do the following :
- write 2-3 asbtraction classes *for* Log4j, i.e. it is used as a
developer's guideline and methodology. Like for example standardizing on
using the full class name as logging Categories, ... The real intent of
these abstraction classes are just to make sure all the commons packages use
it in the same manner as much as possible (so that it is easier to
understand the code and moving it to the Logging JSR later on will all be
easier).
- Make it a rule that if some component of commons need to do logging, it
has to use Log4j.
Is that too restrictive ? Thoughts ?
Thanks
Vincent
> e.g.
>
> import org.apache.commons.logging.*;
>
>
> public Foo {
>
> private static Logger logger = Logger.get( "foo.bar" );
>
> public void doSomething() {
> ...
> logger.log( Level.WARNING, "oh dear something is wrong" );
>
> logger.log( Level.ERROR, "Failed to foo my bar", exception );
> }
> }
>
> The above could sit quite happily on top of the JSR or log4j for sure.
(Not
> sure about logkit, not looked at it yet).
>
> Then in (say) the log4j project the Logger interface could be implemented
> and plugged in using (say) the JAR extension mechanism like JAXP. A file
> META-INF/services/org.apache.commons.logging.Logger on the CLASSPATH would
> contain the class name of the default Logger implementation to use.
>
> Thoughts?
>
> James
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
