Remko Popma created LOG4J2-555:
----------------------------------
Summary: Location-based functionality broken in
AbstractLoggerWrapper subclasses
Key: LOG4J2-555
URL: https://issues.apache.org/jira/browse/LOG4J2-555
Project: Log4j 2
Issue Type: Bug
Components: API, Core
Affects Versions: 2.0-rc1
Reporter: Remko Popma
Assignee: Remko Popma
Fix For: 2.0-rc2
*How to reproduce*
* Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
one with the tool attached to LOG4J2-519)
* In the custom logger provide a public method that invokes the {{log(Level,
String)}} method
* Configure a pattern layout that uses location, like %C for the logger FQCN
* From a sample app, call the public method on your custom logger.
* The output will show the class name of the custom logger instead of the class
name of the calling class in the sample application.
*Cause*
{{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
{{AbstractLogger.class.getName()}}. Then, in {{Log4jLogEvent#calcLocation()}},
when walking over the stack trace elements, the element _following_ the FQCN is
returned. So only loggers that directly subclass from {{AbstractLogger}} will
work correctly. Loggers that inherit from {{AbstractLoggerWrapper}} are two
levels removed from {{AbstractLogger}} and the {{calcLocation()}} method will
not work correctly.
*Solution*
I think {{AbstractLogger}}'s FQCN field should be made non-static, and
initialized to {{getClass().getName()}} in the constructor of
{{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
return the {{StackElement}} whose class name matches the FQCN, instead of the
next element. Location-based functionality should then work for arbitrarily
deep subclass hierarchies of AbstractLogger.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
