As in many other cases, doing something from scratch doesn't prevent you
from repeating the same mistakes :-).
1. (major)As far as I can see, Logging has exactly the same security
problems as log4j ( in logging.LogSource class ). Even worse, at least by
using log4j ( as Ceki mentioned ) you can get secure logging by using
separate hierarchies, while the proposing logging is just hopeless.
2. (major)Using system properties to create the logger... What if you're
in a sandbox ? How many system properties do we need ? ( IMHO system
properties are over abused, they are nice but using them as the only
mechanism is not that good ).
3. (major)Obviously, performance. I believe recycling is essential for
scalability and performance. LogEvent can be used for that ( with some
enhancements ), the current Logging is again hopeless.
4. (minor) I also don't like the use of Iterator
in the interface ( no problem with using collections in the
implementation, but I see no reason for it in the interface - Enumeration
would work as well ).
5. (major)Static all over the place in LogSource. That's the source of all
the problems in Log4j.
6. (minor)newInstance - creating the class with empty constructor and then
setting params is the common pattern almost everywhere.
7. (minor)setLevel, as Peter pointed out.
This is going to be used by (probably) many commons and outside packages,
and ( as mentioned many times) it will be _required_.
Costin
