incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: Logging (again)
Date Thu, 02 Nov 2006 13:55:23 GMT


Rick McGuire wrote:
> Geir Magnusson Jr. wrote:
>> /me wonders what that will do to Harmony....
> I was wondering the same thing.  On Geronimo, I *think* it will work as 
> currently done because the core jar in not placed in endorsed.dirs, so 
> the commons logging classes should be loadable by the core classes.  
> However, this really looks like a problem to me.

What I mean is, does the ORB log on the RI?  I'd like to be able to shut 
off logging for Harmony if so.


> 
> Rick
> 
> 
>>
>> Rick McGuire wrote:
>>> Was the logging infrastructure never implemented?  I was looking at 
>>> the problem Dain reported, and decided a few log entries might be 
>>> nice in this area.  When I went looking for examples of logging in 
>>> the Yoko code, I found some things that are likely to be problems.  
>>> There are currently multiple methods of logging implemented in the 
>>> Yoko code:
>>>
>>>   1. In the bindings code, java.util.logging is used, but in
>>>      conjunction with some celtix logging utils.
>>>   2. In the core code, there is a simple logging interface implemented
>>>      with the ORB that just does System.out.println().  Other places
>>>      use commons logging.
>>>   3. The rmi code is using java.util.logging alone.
>>>   4. The tools code is using java.util.logging + the celtix logging 
>>> utils.
>>>
>>> When we had the vote on this issue earlier, I believe it was decided 
>>> we should be using java.util.logging to avoid having the dependencies 
>>> on the other projects.  It looks like the rmi code is the only one 
>>> that is implemented that way.  I'm probably the most disturbed by the 
>>> use of commons logging in the core code.  Implemented this way, there 
>>> are failures lurking with the recommended method of using the Yoko 
>>> ORB of putting the spec and core jars on either bootstrap classpath 
>>> or the endorsed dirs classpath.  Without pulling in the commons 
>>> logging jar too, there will be some failures occurring because those 
>>> classes using commons logging won't be able to resolve the classes. 
>>> For now, I think this is what needs to be done:
>>>
>>>   1. Rework the home grown logging implementation used in core to use
>>>      java.util.logging in the implementation logic.
>>>   2. The core code using commons logging needs to be converted over to
>>>      standard java.util.logging.
>>>
>>> Rick
>>>
>>
> 
> 

Mime
View raw message