Re: [FYI] Resin 3.0 - logging and JDK 1.4 dependency

Best approach might be to use the commons-logging api from jakarta and then
let the user choose between Log4j or jdk 1.4

Christian Meunier

----- Original Message -----
From: "j.random.programmer" <javadesigner@xxx.com>
To: <resin-interest@xxx.com>
Sent: Tuesday, September 17, 2002 4:53 AM
Subject: Re: [FYI] Resin 3.0 - logging and JDK 1.4 dependency

> > If it were just logging, I'd stick with Resin's old
> > log support. The
> > problem with Apache's log4j is that it's not
> > standard, while
> > java.util.logging is standard. So there's no real
> > value in using log4j.
> >
> > With java.util.logging, I could write a "best
> > practices" document that
> > showed how to use java.util.logging with a
> > servlet-based application.
> > Since that would be completely standard, it would
> > work in any environment.
> >
> > -- Scott
>
> Hmm. As mentioned earlier, java logging has the
> global name space problem unless you hack the
> classloader. (this hack may or may not get mandated
> by the spec). More importantly, most of the
> 1.4 stuff is great except for the logging API anyway.
> The logging API's are hard to use (imho) and
> badly designed when compared to other third-party
> API's.
>
> Here are some Notes about java.util.logging.Logger
>
> * The log(..) methods are *much* slower than the
> logp(...) methods. The log(..) methods try to intuit
> the class and method name from the call stack and
> hence take too much time. These methods should be
> avoided almost completely for logging calls that will
> remain enabled during production.
>
> * The level shorthand methods ( severe(..), warn(..))
> internally delegate to the log(..) methods and hence
> are quite slow. They can still be used however, if
> methods such as fine(..) are probably going to be
> disabled during production. Methods such as severe(..)
> are not expected to be called too often during
> production and hence can remain enabled at production.
>
> * java.util.logging.Handlers assigned to different
> loggers (even for parent vs. child) should be
> different objects. If the same handler object is
> instantiated and assigned to more than one Logger,
> then the LogManager's reset method will attempt to
> remove/close the same handler more than once. This may
> happen at JVM shutdown, for example. Since this class
> writes a shutdown notice to each handler, if the same
> handler is used by more than one Logger, than the
> shutdown notice will not be written properly for each
> Logger (because the shared handler may have been
> closed previously). It is therefore recommended to use
> different handlers for different loggers, even if
> those different handlers point to the same file or
> destination.
>
>
> Best regards,
>
> --j
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! News - Today's headlines
> http://news.yahoo.com
>
>
Received on Mon 16 Sep 2002 20:09:22 -0700