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