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.
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.
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
:-)
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.
Costin
