LOG4J provides all of the facade necessary. If you want to plug it into
another logging mechanism, write an appender for it. That's how I get logs
into syslog, dated logs and into our distributed alarm notifier.
Now, this doesn't address integration with the to be released logging API's
notion of heirarchical categories. But I don't think that's really possible
at this stage either. IAC, tieing them at the output, mod synchronization
issues, is probably more sensible anyway. Something like how stdio and
iostreams are tied in C++.
> -----Original Message-----
> From: James Strachan [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 01, 2001 6:18 AM
> To: [EMAIL PROTECTED]
> 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:-
>
> 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
>
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named. Any use, copying or disclosure by any other person is strictly
prohibited. If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>
