> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
>
> 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:[EMAIL PROTECTED]
> >> 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:[EMAIL PROTECTED]
> >>>> 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:[EMAIL PROTECTED]
> >>>>>> 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-
> >>>>>> [EMAIL PROTECTED]
> >>>>>> For additional commands, e-mail: harmony-dev-
> >>>>>> [EMAIL PROTECTED]
> >>>>>
> >>>>>
> >>>>> ------------------------------------------------------------------
> >>>>> --
> >>>>> -
> >>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >>>>> To unsubscribe, e-mail: harmony-dev-
> >>>>> [EMAIL PROTECTED]
> >>>>> For additional commands, e-mail: harmony-dev-
> >>>>> [EMAIL PROTECTED]
> >>>>>
> >>>>
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >>>> To unsubscribe, e-mail: harmony-dev-
> >>>> [EMAIL PROTECTED]
> >>>> For additional commands, e-mail: harmony-dev-
> >>>> [EMAIL PROTECTED]
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>> For additional commands, e-mail: harmony-dev-
> >>> [EMAIL PROTECTED]
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: harmony-dev-
> >> [EMAIL PROTECTED]
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
