RE: [openorb-devel] controlling loggers

[<Lar...@pp...>]

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