harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@kc.rr.com>
Subject RE: [drlvm] getting activeMQ to run
Date Sat, 23 Sep 2006 19:58:04 GMT
This may be considered a bug, maybe not, but if you write a simple program
that only references the Logger.global field, nothing will be logged out on
Sun's RI 5.0_8 implementation. However, if you lookup the global logger
(Logger.getLogger("global")), then data will be logged out.

Here's the test - run this and nothing will be written:
public class GlobalLogger {
    public static void main(String[] args) {
        Logger global = Logger.global;
        global.severe("hello");
    }
}


Now, if you run this, the a message will be written to the console:
public class GlobalLogger {
    public static void main(String[] args) {
        Logger global = Logger.getLogger("global");
        global.severe("hello");
    }
}

And if you extend it a bit farther with this example, the first message
isn't logged, but the second two are.
public class GlobalLogger {
    public static void main(String[] args) {
        Logger global = Logger.global;
        global.severe("hello");
        
        global = Logger.getLogger("global");
        global.severe("hello again");
        
        global = Logger.global;
        global.severe("and again");
    }
}

Then add another variation by looking up an arbitrary logger (to spark the
LogManager up); here the output is the same as before
public class GlobalLogger {
    public static void main(String[] args) {
        Logger global = Logger.global;
        global.severe("hello");
        
        global = Logger.getLogger("not_global");
        global.severe("hello again");
        
        global = Logger.global;
        global.severe("and again");
    }
}

The last variation then is to use the LogManager instead Logger to get the
global logger; again, the output is the same (only the last two messages are
printed).
public class GlobalLogger {
    public static void main(String[] args) {
        Logger global = Logger.global;
        global.severe("hello");
        
        global = LogManager.getLogManager().getLogger("global");
        global.severe("hello again");
        
        global = Logger.global;
        global.severe("and again");
    }
}

This tells me that the "global" logger is instantiated, but not initialized
with the LogManager's configuration until something calls the LogManager to
start off initialization.

The javadoc alludes to this behavior [1] by stating "The global logger is
initialized by calling Logger.getLogger("global").". It seems that the
guarantee here may just be that the field is available, but it won't be
guaranteed to actually do anything until LogManager is initialized.

An additional test proves how "uninitialized" the global field is; this test
shows that the global field's parent logger is null (it should be root("")),
but after LogManager is loaded, the parent logger is set and it is the root
logger.
public class GlobalLogger {
    public static void main(String[] args) {
        Logger global = Logger.global;
        global.severe("hello");
        System.err.println(global.getParent());
        
        global = LogManager.getLogManager().getLogger("global");
        global.severe("hello again");
        System.err.println(global.getParent());
        
        global = Logger.global;
        global.severe("and again");
        System.err.println(global.getParent());
    }
}

The point of this whole story; regardless of what we do with the root
logger, I think our initialization of the Logger.global was incorrect, or at
least not consistent with the RI. Note, with my change it is now consistent.

-Nathan 
[1] file:///C:/install/jdk/5.0/docs/api/java/util/logging/Logger.html#global

> -----Original Message-----
> From: Nathan Beyer [mailto:nbeyer@kc.rr.com]
> Sent: Saturday, September 23, 2006 2:38 PM
> To: harmony-dev@incubator.apache.org
> Subject: RE: [drlvm] getting activeMQ to run
> 
> > -----Original Message-----
> > From: Geir Magnusson Jr. [mailto:geir@pobox.com]
> >
> > I just gave it a quick look.  Given that you've taken the creation of
> > Loggers away from Logger via it's factory, and now moved it into
> > LogManager, how can we be sure we never have more than one root logger?
> 
> Keep in mind the Logger class is NOT the managing authority of Logger
> instances; this really belongs to LogManager. Logger just provides a
> helper
> method for the prescribed algorithm of LogManager.getLogger() if null
> LogManager.addLogger(new Logger()), return logger.
> 
> Anyway, the LogManager is guaranteed never to maintain more than one
> instance of the root ("") logger because once the logger is constructed in
> LogManager static initializer, it's added to the pool of known loggers.
> Any
> subsequent calls to LogManager.addLogger("") will then fail.
> 
> -Nathan
> 
> >
> > geir
> >
> > On Sep 23, 2006, at 2:18 PM, Nathan Beyer wrote:
> >
> > >> -----Original Message-----
> > >> From: Geir Magnusson Jr. [mailto:geir@pobox.com]
> > >> On Sep 23, 2006, at 1:24 PM, Nathan Beyer wrote:
> > >>
> > >>> The global logger and root logger would just be constructed using
> > >>> new
> > >>> Logger() and then LogManager would set the parent relationship in
> > >>> it static
> > >>> initialization. I'm playing around with it a bit now.
> > >>
> > >> Sorry for being dense, but how is that different from what we have
> > >> now?
> > >
> > > It eliminates the circular execution between the static
> > > initializers and
> > > makes the code more simple and straightforward by having only one
> > > path for
> > > initialization, instead of two paths that execute based which class is
> > > loaded first. I have the code done and all of the tests passing.
> > > I'll check
> > > it in and if it's disliked, we can roll it back.
> > >
> > > -Nathan
> > >
> > >>
> > >>>
> > >>> Also, it seems that the application of a patch to create revision
> > >>> 436703
> > >>> seems to have broken another application, in this case Tomcat. The
> > >>> public
> > >>> readConfiguration method was replaced with a call to
> > >>> readConfigurationImpl,
> > >>> which means the LogManager override mechanism won't work correctly.
> > >>> I'm
> > >>> fixing that on.
> > >>>
> > >>> -Nathan
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Geir Magnusson Jr. [mailto:geir@pobox.com]
> > >>>> Sent: Saturday, September 23, 2006 5:48 AM
> > >>>> To: harmony-dev@incubator.apache.org
> > >>>> Subject: Re: [drlvm] getting activeMQ to run
> > >>>>
> > >>>>
> > >>>> On Sep 23, 2006, at 12:00 AM, Nathan Beyer wrote:
> > >>>>
> > >>>>>
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Gregory Shimansky [mailto:gshimansky@gmail.com]
> > >>>>>> Sent: Friday, September 22, 2006 7:43 PM
> > >>>>>> On Saturday 23 September 2006 04:20 Geir Magnusson Jr.
wrote:
> > >>>>>>>
> > >>>>>>> Hm.
> > >>>>>>>
> > >>>>>>> LogManger's initializer does
> > >>>>>>>
> > >>>>>>>    Logger root = Logger.getLogger("");
> > >>>>>>>
> > >>>>>>> and Logger has
> > >>>>>>>
> > >>>>>>>    public final static Logger global = Logger.getLogger
> > >>>>>>> ("global");
> > >>>>>>>
> > >>>>>>> which eventually executes
> > >>>>>>>
> > >>>>>>>     LogManager man = LogManager.getLogManager();
> > >>>>>>>
> > >>>>>>> and around we go.
> > >>>>>>>
> > >>>>>>> So why don't we always run aground with this?  Why
is this the
> > >>>>>>> first
> > >>>>>>> time we see this?
> > >>>>>>
> > >>>>>> I think that only stack trace of NPE can show the real
reason of
> > >>>>>> the
> > >>>>>> problem... If it is NPE (uninitialized field has to be
null),
> > >>>>>> otherwise my
> > >>>>>> guess could be wrong.
> > >>>>>
> > >>>>> Wouldn't a simple approach to fixing this be create the root
> > >>>>> logger
> > >>>>> with a
> > >>>>> custom implementation of Logger instead of using Logger.getLogger
> > >>>>> ("") to
> > >>>>> create it. Also, the same thing would be done for the global
> > >>>>> logger
> > >>>>> initialization. This could be done with a package-private
> > >>>>> constructor just
> > >>>>> for this special purpose. This way the initialization of
> > >>>>> LogManager
> > >>>>> can use
> > >>>>> Logger, but the initialization of Logger doesn't use LogManager.
> > >>>>>
> > >>>>
> > >>>> How would the root logger be a Logger?
> > >>>>
> > >>>> geir
> > >>>>
> > >>>>
> > >>>>> -Nathan
> > >>>>>
> > >>>>>>
> > >>>>>> The workaround for such cases is simple, in methods like
> > >>>>>>
> > >>>>>>     void m () {
> > >>>>>>         f.m2();
> > >>>>>>     }
> > >>>>>>
> > >>>>>> it is necessary to write
> > >>>>>>
> > >>>>>>     void m () {
> > >>>>>>         if (f == null)
> > >>>>>>             initf();
> > >>>>>>
> > >>>>>>         f.m2();
> > >>>>>>     }
> > >>>>>>
> > >>>>>> This, in case may cause infinite recursion because in case
> > >>>>>> initialization
> > >>>>>> of
> > >>>>>> field f may still refer to method m in other classes, but
it is
> > >>>>>> easier to
> > >>>>>> resolve.
> > >>>>>>
> > >>>>>> --
> > >>>>>> Gregory Shimansky, Intel Middleware Products Division
> > >>>>>>
> > >>>>>> -----------------------------------------------------------------
> > >>>>>> --
> > >>>>>> --
> > >>>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
> > >>>>>> To unsubscribe, e-mail: harmony-dev-
> > >>>>>> unsubscribe@incubator.apache.org
> > >>>>>> For additional commands, e-mail: harmony-dev-
> > >>>>>> help@incubator.apache.org
> > >>>>>
> > >>>>>
> > >>>>> ------------------------------------------------------------------
> > >>>>> --
> > >>>>> -
> > >>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
> > >>>>> To unsubscribe, e-mail: harmony-dev-
> > >>>>> unsubscribe@incubator.apache.org
> > >>>>> For additional commands, e-mail: harmony-dev-
> > >>>>> help@incubator.apache.org
> > >>>>>
> > >>>>
> > >>>>
> > >>>> -------------------------------------------------------------------
> > >>>> --
> > >>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
> > >>>> To unsubscribe, e-mail: harmony-dev-
> > >>>> unsubscribe@incubator.apache.org
> > >>>> For additional commands, e-mail: harmony-dev-
> > >>>> help@incubator.apache.org
> > >>>
> > >>>
> > >>> --------------------------------------------------------------------
> > >>> -
> > >>> Terms of use : http://incubator.apache.org/harmony/mailing.html
> > >>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > >>> For additional commands, e-mail: harmony-dev-
> > >>> help@incubator.apache.org
> > >>>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> > >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > >> For additional commands, e-mail: harmony-dev-
> > >> help@incubator.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message