Bug 1079106
| Summary: | Log4j Logger.getParent() inconsistent | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | James Livingston <jlivings> |
| Component: | Logging | Assignee: | James Perkins <jperkins> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Nikoleta Hlavickova <nziakova> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.2.2 | CC: | joallen, kkhan |
| Target Milestone: | DR4 | ||
| Target Release: | EAP 6.4.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1148632 | ||
| Bug Blocks: | |||
Open PR for log4j-jboss-logmanager https://github.com/jboss-logging/log4j-jboss-logmanager/pull/6 Verified with EAP 6.4.0.DR6. |
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. 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.