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

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

With hindsight I probably saw the {{getMessageFactory}} method but thought I 
could avoid using it. 

I just updated the Generate tool in LOG4J2-519 and having to go through the 
{{log(Marker, String, Level, Message, Throwable)}} method was quite painful. 
Method implementations are now three or four lines instead of one line, and 
there is a need to pass {{null}} parameters now. 

I'm not complaining, just noticing that the previous implementation was more 
intuitive so documentation is probably necessary if the longer and less 
intuitive implementation is the only correct way to do things.

> 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