At 11:36 15.08.2001 -0700, [EMAIL PROTECTED] wrote:
>Just MHO, I really like log4j - but there are few small show-stoppers for
>me. If Ceki can fix those, I would be a happy user, if not I'll keep
>looking around for an alternative.
>
>
>1. Garbage collection. LogEvent is not recycled and not recyclable ( since
>the only way to set params is via constructor ).
>
>2. Performance/GC part 2. User code has no way to prevent allocating
>objects and GC. There are few solutions - like using
>Category.callAppenders() directly, but that doesn't solve the problem
>until a solution for recycling the LogEvent is in place.
Hi Costin,
We do indeed create a fresh LoggingEvent every time a positive
decision is made to log.
Note that the LoggingEvent will not be created if logging is turned of
entirely or if it is disabled for the category and priority associated
with the log request.
On the other hand, the 1-2 microseconds performance overhead involved
in the creation of a fresh LoggingEvent is dwarfed by the time it
takes to format the output and write it to the output device
(e.g. disk, console, syslog, wire..).
Just as importantly, log4j components can be called from multiple
threads. As such, we now have to start worrying about pooling
LoggingEvent instances, worry about their synchronization etc. As I
see it, the 0.1% performance gain is not worth the effort. Or is it?
>3. Security. If log4j is included in the main classpath ( i.e. tomcat/lib,
>etc ), _all_ webapps have access to _all_ loggers. That means
>untrusted_app1 can see and modify logging for untrusted_app2 or for
>trusted_app3.
That's a very interesting problem. One solution is to have different
webapps use different hierarchies. This feature was actually
developed for Tomcat.
>There is another small problem, the current source is a bit messy, with a
>lot of classes that are not used mixed with important interfaces, the API
>not clearly separated from impl. So I'll add:
>
>4. Better interfaces. You can't replace Category ( with a different
>impl - that would be very important if you want to integrate with a
>different logging mechanism ). The impl. ( be it default or advanced
>appenders ) has to be cleanly separated from the intrefaces the user sees.
>( that's probably just my sensibility to mess - after dealing with tc3.0
>:-)
Better documentation is definitely needed. As for better interfaces, your concrete
suggestions are always welcome.
>All of those are solvable - and I'm all +1 for using log4j, as soon as
>this is done. But doing so before we have a good answer is ( IMHO ) a bad
>idea. Sorry Ceki, I really like log4j and I don't want this to sound very
>negative, there are just problems I have right now.
Sure, no sweat.
--
Ceki Gülcü - http://qos.ch
