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

Bruce Brouwer commented on LOG4J2-547:
--------------------------------------

My comments of performance were me remembering the code I saw in 
{{ClassLoaderContextSelector}}, which I think actually doesn't come into play 
in this scenario. So, it probably is as simple as getting the stack trace (the 
expensive part) and iterating over the list doing a few string comparisons 
(maybe a few hundred). Would it help if I made a little performance test 
comparison? 

As for my comment about top-down being more technically correct, I was thinking 
that in the short stack trace example that Remko outlined, I think the top 
LoggerPrintStream should report its caller as 
{{FilterOutputStream.someMethod()}}, not 
{{ApplicationClass_TheCaller.theMethod()}}. However, in probably 90%+ of cases, 
the more useful caller to report would be 
{{ApplicationClass_TheCaller.theMethod()}}, which would be discovered by the 
bottom-up approach. It's an interesting edge case, but probably not worth 
worrying about. 

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