incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conrad O'Dea" <co...@iona.com>
Subject Re: Logging
Date Fri, 21 Apr 2006 13:15:20 GMT
Hi Balaji,

On 21 Apr 2006, at 14:08, Mosur Ravi, Balaji wrote:

> I like this idea... Since yoko is going to be used by different  
> projects (celtix, geronimo), we should be able to log to any system...
>
> If I understand you correctly then what you suggest is to use the  
> java.util.Logger as the logging API instead of creating our own  
> logging api... We will have a log4j Logger & default jdk logger...
>
> So can't we do the same thing the other way around, use the log4j  
> logging api & have the a custom jdk logger based on the log4j api...
>
> I haven't worked much with either api to know which has the  
> complete list of logging api's, i.e which can be considered as a  
> superset, because it would be hard to map from a subset to a  
> superset...
>
> If log4j has the complete list of log api's, then we will use it  
> instead...
>


AFAIK, the interfaces are pretty close in what they offer but I think  
that the JDK interface is slightly richer, certainly in terms of  
straightforward logging.

+1 for Dan's compromise proposal.


rgds
Conrad

>
> -1 to defining our own logging API.   That is silly when there is a
> perfectly good logging API that meets the requirements  (logging
> requirements, not integration requirements), is very simple to use,  
> that
> is already installed on everyones machines, does not have "version
> number" issues, etc...
>
> Also, for all parts that are based on, use, or derive from Celtix, you
> will have to deal with JDK logging anyway.   All logging in Celtix  
> is JDK
> logging.   Thus, the tools and bindings stuff might as well just  
> use JDK
> logging since that is where a large number of the log messages are  
> going
> to go anyway.    There is no plans (or desire) to change Celtix at  
> this
> point.  It would be a lot of work for little/no gain.
>
>
> How is this for an idea/comprimise:
> For all logging, we use JDK Logger objects.   However, instead of  
> calling
> Logger.getLogger(....), we create a utility class and call:
> LoggerFactory.getInstance().getLogger(.....).  (several varieties of
> getLogger calls).   The default factory just passes them on to JDK  
> Logger
> getLogger calls.   However, if you want, you can replace the
> LoggerFactory with one that will wrapper log4j Loggers or whatever  
> else
> you want.   The JDK Logger object is not final (or have any final
> methods) so we can use it as the API for logging, the underlying  
> logging
> can be just about anything.     I COULD be convinced to do  
> something in
> similar in Celtix as this would JUST affect the Logger creation
> mechanisms, not any of the actual logging.
>
> What are peoples thoughts about that?
>
> Enjoy!
> Dan
>
>
>
>>
>> -1 for using JDK logging directly
>>
>> I detailed this in my earlier messages, the short version is that  
>> most
>> people use/want/need log4j. Those people include myself for my  
>> apps at
>> work. Since Geronimo uses commons logging I assume that G won't  
>> easily
>> be able drop support for log4j either, but Geronimo commiters might
>> have more details on that.
>>
>> /Lars
>
> -- 
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727  C: 508-380-7194
> daniel.kulp@iona.com
>


Mime
View raw message