incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: [VOTE] Official logging platform for Yoko
Date Fri, 09 Jun 2006 18:32:19 GMT
I just want to point out that I am not a committer so my negative  
vote is not a veto.  Further, I don't consider this a technical  
issue, and majority rules.

On Jun 9, 2006, at 6:23 AM, Sakala, Adinarayana wrote:

> New Results:
>>> [ ] Use java.util.logging directly - 10 (Commiter)  1 (Non Commiter)
>>> [ ] Use slf4j/log4j - 2 (Committer) 1 (Non Commiter)
>>> [ ] Define our own logging API that is not an LCD type API - 2  
>>> (Commiter)
>>> [ ] Define our own logging API that is a "lowest common denominator"
>>> type API
>
>> Util logging will be a big problem for geronimo since we use commons
>> logging piped to log4j by default.  If yoko chose util logging, I'm
>> not sure what we could do.
> Dain, why cant geronimo commons logging piped to java.util. instead  
> of log4j?

How about I flip that.  Why can't yoko use log4j or CL?  The answer  
is we choose to do something different and I doubt people will  
change.  Last time I checked (2 years ago) Geronimo was capable of  
using util logging or log4j (user selectable), but no one does so I  
doubt the code works.

> Is that what you are proposing when you say forking?

I'm not proposing anything.  I saying that if Yoko chooses util  
logging, it will be a huge problem for anyone using another logging  
framework.  There are a few ways to deal with it.  The easiest would  
be if Yoko simply created a custom log interface and a hook to  
replace the implementation it uses.  Without out that, someone either  
needs to figure out how to hack util logging to pipe it to another  
log stream or they need to fork Yoko.

> That way Yoko can focus on providing standard support based on  
> java.util.logging standard API that helps all the projects in a  
> standard way Harmony, Geronimo, Celtix.

The reality is just about every choice you have for a logging  
framework is used by some project.  By choosing to use what I will  
call an "output" framework directly instead of an "input" only  
framework (e.g. commons logging, custom, or monitors), you make the  
jobs of someone using a different output framework very difficult.

Anyway, this is just my (non-committer) opinion, and I much rather  
see any CORBA impl, so I say just choose what is easiest for you,

-dain



Mime
View raw message