incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: logging (was: coding standard)
Date Mon, 13 Mar 2006 19:25:41 GMT
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  

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.

View raw message