[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13937728#comment-13937728
]
Bruce Brouwer edited comment on LOG4J2-555 at 3/17/14 12:41 PM:
----------------------------------------------------------------
After thinking some more about my change to log4j-jcl Log4jLog, I could quite
easily be convinced to revert that back to extending AbstractLoggerWrapper. I
could see some convenience in simply casting Log4jLog between jcl's Log and
log4j's Logger interface. For example, if I was using jcl's interface to log4j,
I could simply cast to a jcl Log to log4j's Logger to use the different logger
streams depicted in LOG4J2-547.
However, if we do that, then we should probably do the same thing to
log4j-slf4j-impl's SLF4JLogger so it can also be cast to log4j's Logger
interface. I suppose this change could be tracked in a separate JIRA.
So what do people think? Should these alternate logging implementations be made
so it is easy to cast to log4j's Logger interface, or should we try to keep the
interface to these alternate logging implementations as free as possible of
log4j public methods?
Oh, and I now see that my comment about log4j-to-slf4j SLF4JLogger.logMessage
was in error. It is fine as it is (which is how it remains in the patch)
I also see that I was remiss in finishing up JavaDoc. If people like the
direction of {{log4j-555-bbrouwer-2.patch}}, I can make a new patch, or I will
commit to submitting a documentation patch if this is applied before that new
patch.
was (Author: bruce.brouwer):
After thinking some more about my change to log4j-jcl Log4jLog, I could quite
easily be convinced to revert that back to extending AbstractLoggerWrapper. I
could see some convenience in simply casting Log4jLog between jcl's Log and
log4j's Logger interface.
However, if we do that, then we should probably do the same thing to
log4j-slf4j-impl's SLF4JLogger so it can also be cast to log4j's Logger
interface. I suppose this change could be tracked in a separate JIRA.
So what do people think? Should these alternate logging implementations be made
so it is easy to cast to log4j's Logger interface, or should we try to keep the
interface to these alternate logging implementations as free as possible of
log4j public methods?
Oh, and I now see that my comment about log4j-to-slf4j SLF4JLogger.logMessage
was in error. It is fine as it is (which is how it remains in the patch)
I also see that I was remiss in finishing up JavaDoc. If people like the
direction of {{log4j-555-bbrouwer-2.patch}}, I can make a new patch, or I will
commit to submitting a documentation patch if this is applied before that new
patch.
> 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
>
> Attachments: LOG4J2-555-delegate.patch, log4j2-555-bbrouwer-2.patch,
> log4j2-555-bbrouwer.patch
>
>
> *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.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
