[
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: [email protected]
For additional commands, e-mail: [email protected]