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 04:00:49 GMT


> -----Original Message-----
> From: Gregory Shimansky [mailto:gshimansky@gmail.com]
> Sent: Friday, September 22, 2006 7:43 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [drlvm] getting activeMQ to run
> 
> On Saturday 23 September 2006 04:20 Geir Magnusson Jr. wrote:
> > On Sep 22, 2006, at 7:32 PM, Gregory Shimansky wrote:
> > > On Friday 22 September 2006 22:39 Geir Magnusson Jr. wrote:
> > >> First, thanks so much for the fast response and good solution.
> > >>
> > >> I don't see any problem with this patch, but you're right - I don't
> > >> understand why we have it, since Logger should set it's "global"
> > >> field to getLogger("global") in the static initialization.
> > >
> > > Static initialization doesn't guarantee that the field is
> > > initialized when you
> > > need it.
> > > I've seen it several times in classlib initialization. It happens
> > > because <clinit> method is called only once in the stack of the
> > > calling
> > > methods (or there could be infinite recursion). If <clinit> is
> > > somewhere up
> > > the stack it won't be called again. But if some field of the class
> > > which is
> > > executing <clinit> up the stack already is needed down the stack by
> > > some
> > > other called classes' methods (called from the up the stack
> > > <clinit>), it may
> > > be still uninitialized.
> >
> > 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.

-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


Mime
View raw message