[ 
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917313#comment-13917313
 ] 

Remko Popma commented on LOG4J2-555:
------------------------------------

Interesting! I see the difficulty now: apps may call a method in the subclass 
or in AbstractLogger, so any stacktrace-walking should work for both.

If custom loggers _must_ use the {{log(Marker, String, Level, Message, 
Throwable)}} method, {{AbstractLogger}} should at least make its 
{{MessageFactory}} available to subclasses. The fact that this is not available 
was what made me call the other {{log}} methods in the custom logger in 
LOG4J2-519.

Still, it seems a bit... fragile to ask subclasses to use only that particular 
method. I'll think a bit more if there isn't an alternative. Thanks for the 
explanation!

> 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

Reply via email to