[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925424#comment-13925424
]
Bruce Brouwer commented on LOG4J2-555:
--------------------------------------
That MsgBuilder stuff looks interesting. I'm not sure I'm for it yet. It is not
incompatible with my ideas.
I'm working on my own patch for this that I will post soon and I hope to
receive feedback.
There are a few things I'm trying to do to make it easier for things using the
wrapper.
* Instead of FQCN invading the API, which isn't terribly flexible, I've created
a SourceLocator interface and related classes. This way custom loggers could
use multiple FQCNs or something completely different.
* Make the interface LoggerProvider in the spi package which extends Logger and
which AbstractLogger implements. This has a few more isEnabled and log methods
available which make it possible for extended loggers to use efficiently.
LoggerContext would start to return LoggerProvider instead of just Logger, and
other code would stop casting to AbstractLogger and could instead use the
LoggerProvider interface.
That second point ends up making more methods public on the concrete
implementations. I had an alternative idea in LOG4J2-562 that would prevent
these methods from needing to go public. I'll post my patch soon. I'll try to
get performance numbers, too.
> 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
>
>
> *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
