On Mar 12, 2006, at 12:30 AM, Lars Kühne wrote:
Alan D. Cabrera wrote:
The only thing that I find questionable in the Geronimo coding
standard for yoko is the use of commons logging. For example I'm
not convinced that j.c.l would work well when yoko is used inside
Harmony. I like the current dependency injection design for
loggers. OpenORB uses something similar (avalon logkit), it works
just fine, and I see none of the j.c.l classloader problems.
IIUC, log4j is the hands down favorite. Does it suffer any of the
j.c.l classloader problems?
I don't think so, and personally I could live with log4j. Geir is
in a much better position to answer that question for Harmony. I
would find it odd if Harmony would include log4j.
Like most people these days, I like dependency injection, and this
is what the current code does. Why not stick with it and just
change the current Logger interface a bit (e.g. don't make it a
CORBA object, add isDebugEnabled(), etc.)?
I think projects should avoid logging entirely. The problem with
logging is the information that comes out of it is useless to other
software because it is encoded into user readable strings. IMHO, the
best policy is to use a Monitor. For example see the following XBean
Monitors:
http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-kernel/src/
main/java/org/apache/xbean/kernel/ServiceMonitor.javahttp://
svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-kernel/src/main/
java/org/apache/xbean/kernel/KernelMonitor.java
These interfaces are incredibly useful when testing, XBean because I
can now have direct access to exceptions and other detailed
information that otherwise would be encoded into a string. For a
normal running server, we will simply convert the monitor events to
(localized) strings and log them using what ever logging system
people want.
The problem with monitors is they take a lot more thought and effort
to design and code, and I personally don't use them in most cases. I
did in the XBean kernel because I think the kernel interfaces are
critical to the success of the project.
For most day to day code, I suggest we create our own Log interface
which is injected into the components. The biggest problem with
commons logging is that it is common. MX4J has it's own interface
which is very close to CL, but it is easy to work with because you
can easily install any implementation.
-dain
