Re: [openorb-devel] controlling loggers

[Joncheng K. <ck...@sy...>]

As far as I remember, the reason for OpenORBLoader to "replace" the 
logger is that there is no way to set the logging priority once a logger 
is created. Because OpenORB allows setting the logging priority in the 
XML-based configuration, we're facing two issues: 1) you need a logger 
for the Configurator to parse the configuration, and 2) you need to set 
the logging priority right according to the configuration.

We may, upon an agreement, to take the following approach: If a logger 
is given by the LOGGER property, the logging priority property will be 
ignored. In that case, you basically ignore the priority setting and not 
replace the given logger. Does it sound reasonable to everyone?

Joncheng

Lar...@pp... wrote:

>Hi,
>
>if possible I'd like to avoid creating a branch. I can live with the Trace
>class in release 1.4.0. We can do the logger cleanup I proposed (my third
>point) after the release, together with the changes Joncheng proposed.
>
>However, not being able to log at all from Initializers is a bug that should
>be fixed, right? If noone knows the reason for creating a new logger (my
>first point below) I'll investigate executing the logger replacement in
>OpenORBLoader only if "LOGGER" is not passed in via the Properties.
>
>The fix should qualify as a non-fundamental change, I'll only touch a few
>lines in OpenORBLoader. If you disagree with the proposed changes please
>shout before the weekend.
>
>Lars
>
>  
>
>>-----Original Message-----
>>From: Michael Rumpf
>>Sent: Tuesday, May 18, 2004 10:51 PM
>>To: Lars.Kuehne
>>Cc: ope...@li...
>>Subject: Re: [openorb-devel] controlling loggers
>>
>>
>>On Tue, 2004-05-18 at 11:45, Lars.Kuehne wrote:
>>    
>>
>>>Hi,
>>>
>>>I'm having difficulties to control the logger that is used in
>>>ORBInitializers. In our application we are using log4j, and 
>>>      
>>>
>>when I create an
>>    
>>
>>>ORB, I pass in a Log4JLogger as the "LOGGER" property. However the
>>>initializer is logEnabled() with a totally unrelated logger...
>>>
>>>The problem is that the ORBLoader is not consistently using 
>>>      
>>>
>>the logger is
>>    
>>
>>>passed in. Halfway through the initialization it replaces the logger
>>>
>>>            m_logger = Trace.getNewLogger( 
>>>      
>>>
>>Trace.getPriorityFromName( trclvl
>>    
>>
>>>) );
>>>
>>>and a child logger of that new logger is used to logEnable 
>>>      
>>>
>>the initializers.
>>    
>>
>>>Unfortunately Trace.getNewLogger() is hardcoded to return a 
>>>      
>>>
>>new LogKitLogger
>>    
>>
>>>(and not a Log4jLogger we need).
>>>
>>>Questions:
>>>*	What is the purpose of creating a new logger and not 
>>>      
>>>
>>using the one I
>>    
>>
>>>passed in?
>>>*	Is there some configuration option I missed that lets 
>>>      
>>>
>>me write the
>>    
>>
>>>Initializer logs to my log4j backend?
>>>*	Why is the Trace class necessary at all? At least when 
>>>      
>>>
>>using a log4j
>>    
>>
>>>backend, creating child loggers for tracing different subsystems
>>>("orb#ldr1234.iiop", "orb#ldr1234.servermanager", ...) 
>>>      
>>>
>>would seem much more
>>    
>>
>>>natural to me. You could set logging priorities, redirect 
>>>      
>>>
>>parts of the logs
>>    
>>
>>>to different appenders, etc. just by configuring 
>>>      
>>>
>>log4j.properties the way
>>    
>>
>>>you need it...
>>>      
>>>
>>I think you are facing some evolutionary code. Quite a few people had
>>their fingers on the code, incl. me, and not always a global 
>>refactoring
>>in mind. I would like to get rid of most of the 
>>initialization stuff by
>>replacing the code with something Joncheng and Polar did for the
>>ApacheORB, i.e. getting rid of the XML stuff. This would lead 
>>to a much
>>cleaner way OpenORB is bootstrapped, incl. initialization of 
>>the logging
>>layer. Joncheng proposed to include something for OpenORB 1.4.0. Our
>>policy do not permit fundamental changes on the code while in beta.
>>Maybe you can branch the codebase so that work can continue without
>>being blocked by the beta...?
>>
>>Unfortunately I'm currently busy with getting a new version of our
>>AppServer out of the doors where we are facing a lot of OpenORB
>>1.4.0BETA related troubles. My current efforts will be 
>>limited to fixing
>>the problems we have... :(
>>
>>Michael
>>
>>
>>    
>>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: SourceForge.net Broadband
>Sign-up now for SourceForge Broadband and get the fastest
>6.0/768 connection for only $19.95/mo for the first 3 months!
>http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
>_______________________________________________
>openorb-devel mailing list
>ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openorb-devel
>
>
>  
>