[ 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