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?
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: [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]
