incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nolan, Edell" <>
Subject coding standard and logging
Date Tue, 04 Apr 2006 14:49:22 GMT
I know there were plenty of emails on these issues already but we don't seem to have 
agreed what approch we are taking. It would be great if we can get these narrowed down
1)  Coding standard to be used 
2)  Logging approach.
1) The last suggestion for the coding standard was 

( <>


2) The last email for the logging - is below 

We could use the LogUtils class from celtix which is using the jdk1.5 logging.

Look at the logging and i18n

or put these in yoko

cheers, Edell.

> On Mar 12, 2006, at 12:30 AM, Lars K├╝hne wrote:

>> 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:

> <>

> main/java/org/apache/xbean/kernel/ServiceMonitor.javahttp://


> java/org/apache/xbean/kernel/

> 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.

Looks nice.


> 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.


It would be *much* more difficult for an ORB implementation, because the system is so much
bigger than XBean.

> For most day to day code, I suggest we create our own Log interface 

> which is injected into the components.



> [...] 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.


Yeah, very similar to the Avalon Logger interface OpenORB uses:

The only thing that is really missing in Avalon is trace(), and maybe we should allow logging
Objects or Serializables instead of Strings.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message