geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karan Malhi" <karan.ma...@gmail.com>
Subject Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
Date Thu, 30 Aug 2007 01:12:43 GMT
Or maybe in one of the very first  OpenEJB methods called by Geronimo
to start openejb in embedded mode we could add some code like
System.setProperty("openejb.logging","external");

the first time the Logger class is loaded, we check for this property
and if it has a value of external, then we do not use
embedded.logging.properties otherwise we assume our default strategy.

On 8/29/07, Karan Malhi <karan.malhi@gmail.com> wrote:
> Just thinking, could we do something with a Thread Context, i.e. if it
> is an App Server Thread Context, then we do not use
> embedded.logging.properties file, if it is an OpenEJB thread context
> which is trying to access the Logger, then if we go with our existing
> strategy.
>
> I dont even know what I am saying here and dont have a clue how it
> could be done, but just thinking maybe this could lead to something ;)
>
> On 8/29/07, Karan Malhi <karan.malhi@gmail.com> wrote:
> > The only way I know of is to do something like
> >
> >
> > Logger openejb = Logger.getInstance(LogCategory.OPENEJB, Foo.class);
> > boolean configured = openejb.getAllAppenders().hasMoreElements();
> >
> > If there is an appender for OPENEJB then configured will be true and
> > we will know that OPENEJB was configured explicitly.
> >
> > Okay, now here are some of the major flaws with this approach,
> > 1. If rootLogger is configured by the user and has an appender, then
> > OPENEJB will inherit the appender. So even if OPENEJB is not
> > explicitly configured, it will still have an appender.
> > 2. Lets say we first check and find that rootLogger does not have an
> > appender, in that case if OPENEJB has an appender, then we are sure
> > that OPENEJB is configured explicitly.
> > 3. If rootLogger and OPENEJB do not have an appender, then we can
> > "guess" that OPENEJB is not configured, but we can still have a case
> > where OPENEJB was configured explicitly, but somebody forgot to add an
> > appender to it.
> >
> > We will have to mention that if OPENEJB is not configured explicitly
> > with an appender, then logging will not work.
> >
> >
> > On 8/29/07, David Blevins <david.blevins@visi.com> wrote:
> > >
> > > On Aug 28, 2007, at 7:35 PM, Karan Malhi wrote:
> > >
> > > > I dont even think they can change log levels. We used the logic that
> > > > - if conf is present - use logging.properties
> > > > - if conf is present - logging.properties is absent- install
> > > > logging.properties and use it
> > > > - if conf is absent, assume embedded and use
> > > > embedded.logging.properties which is available in the openejb-core.jar
> > > > .
> > > > - if embedded.logging.properties is not found in openejb-core.jar then
> > > > rely on the log4j.configuration system property
> > > >
> > > > So, if openejb is embedded within GERONIMO,  no matter what log levels
> > > > they set in the var/logs directory, those settings should never take
> > > > effect.
> > > >
> > > > I think what we can do though is that Geronimo can set the
> > > > log4j.configuration system property in the
> > > > o.a.g.openejb.OpenEjbSystemGBean and we can then do the following:
> > > > - if conf is absent, assume embedded, look for log4j.configuration
> > > > system property. if log4j.configuration property is set, then use it,
> > > > if it is absent then use embedded.logging.properties
> > > >
> > > > Do you think I am on the right track and does the above makes any
> > > > sense?
> > >
> > > Do you know if there is a way to check to see if the "OpenEJB" log4j
> > > category has been explicitly configured?  If so we could skip the
> > > whole business and assume whatever embedded environment we're in has
> > > taken responsibility for logging.
> > >
> > > -David
> > >
> > >
> >
> >
> > --
> > Karan Singh Malhi
> >
>
>
> --
> Karan Singh Malhi
>


-- 
Karan Singh Malhi

Mime
View raw message