logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Goers (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
Date Sun, 02 Mar 2014 06:35:19 GMT

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

Ralph Goers edited comment on LOG4J2-555 at 3/2/14 6:33 AM:
------------------------------------------------------------

AbstractLogger is correct.  Applications that invoke its methods will work correctly.  The
problem here is that all the calls from a custom logger should use the log(final Marker marker,
final String fqcn, final Level level, final Message data, final Throwable t) method of AbstractLoggerWrapper
and provide the fqcn.

I should add that at one point AbstractLogger had code similar to what you are suggesting.
It generally did not work because in most cases the application is not calling a method in
the subclass but is directly calling a method in AbstractLogger, thus the FQCN needs to be
for AbstractLogger, not the subclass.


was (Author: ralph.goers@dslextreme.com):
AbstractLogger is correct.  Applications that invoke its methods will work correctly.  The
problem here is that all the calls from a custom logger should use the log(final Marker marker,
final String fqcn, final Level level, final Message data, final Throwable t) method of AbstractLoggerWrapper
and provide the fqcn.

> 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message