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

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

Reply via email to