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

Remko Popma commented on LOG4J2-547:
------------------------------------

FYI, this logic lives in 
[Log4JLogEvent#calcLocation|http://logging.apache.org/log4j/2.x/log4j-core/xref/org/apache/logging/log4j/core/impl/Log4jLogEvent.html#311];
 I think the expensive part of this method is the call to 
{{Thread.currentThread().getStackTrace()}}, and looping over the resulting 
array to do String comparisons is relatively cheap. So I suspect the 
performance impact would be minimal. (On the other hand I have seen 
Spring-based applications with ridiculously deep stack traces, and it does all 
add up, so you could be right...)

About the corner case of LoggerPrintStream #1 (providing the FQCN) wrapping a 
FilterOutputStream, wrapping another LoggerPrintStream #2 (also providing an 
FQCN), wouldn't the stack trace look like the below, so only the bottom-up 
approach would give correct results?

{code}
LoggerPrintStream.someMethod() 
FilterOutputStream.someMethod() 
LoggerPrintStream.someMethod() 
ApplicationClass_TheCaller.theMethod() <-- the calling class we want to print 
in location info
{code}

> Update LoggerStream API
> -----------------------
>
>                 Key: LOG4J2-547
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-547
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 2.0-rc1
>            Reporter: Matt Sicker
>            Assignee: Ralph Goers
>             Fix For: 2.0
>
>         Attachments: 0001-PrintStream-API-update.patch, 
> log4j2-547-bbrouwer.patch, log4j2-loggerStream.patch
>
>
> I've got some ideas on how to improve the LoggerStream idea that I added a 
> little while ago. The main thing I'd like to do is extract an interface from 
> it, rename the default implementation to SimpleLoggerStream (part of the 
> SimpleLogger stuff), and allow log4j implementations to specify a different 
> implementation if desired.
> In doing this, I'm not sure where specifically I'd prefer the getStream 
> methods to be. Right now, it's in Logger, but really, it could be in 
> LoggerContext instead. I don't think I should be required to get a Logger 
> just to get a LoggerStream.
> Now if only the java.io package used interfaces instead of classes. This 
> would be so much easier to design!



--
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

Reply via email to