[
https://issues.jboss.org/browse/LOGMGR-95?page=com.atlassian.jira.plugin....
]
James Livingston commented on LOGMGR-95:
----------------------------------------
Logger a = Logger.getLogger("a");
Logger abc = Logger.getLogger("a.b.c");
Logger ab = Logger.getLogger("a.b");
With the log4j bridge, abc.getParent().getName() == "a" but with original log4j
it is "a.b". An alternative would be to have Logger.getParent() get the parent
node and then convert that back to a Logger (so dropping updateParents() altogether), but
I believe that would require Logger to have changes from upstream which it doesn't
currently have.
Logger.getParent() isn't particularly well documented as to what it is supposed to do,
but the bridge's current behaviour is not identical to Log4J's.
Log4j Logger.getParent() inconsistent
-------------------------------------
Key: LOGMGR-95
URL:
https://issues.jboss.org/browse/LOGMGR-95
Project: JBoss Log Manager
Issue Type: Bug
Security Level: Public(Everyone can see)
Reporter: James Livingston
Assignee: David Lloyd
Log4j Loggers have a getParent() method, whose return value is set up by
JBossLogManagerFacade.updateParents(). The method locates the closest parent node which
has an existing Log4J logger created *at the time*. This results in the parent being
different depending on the order Log4j loggers are used in.
Consider:
Logger.getLogger("a");
Logger.getLogger("a.b.c");
Logger.getLogger("a.b");
When the second line causes updateParents() to be called, LoggerNode.getOrCreate() has
already created the intermediate "a.b" node. That does not yet have a Log4j
Logger created, so the Logger for "a" is returned. Original log4j would have
returned "a.b" due to it using the parent structure in the implementation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira