[
https://issues.apache.org/jira/browse/LOG4J2-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14117864#comment-14117864
]
Matt Sicker commented on LOG4J2-809:
------------------------------------
Scattered about are various methods to get the caller class name. This tends to
work like the getCallerClass(int) method inside LogManager which is actually
rather simple:
{code}
private static String getClassName(final int depth) {
return new Throwable().getStackTrace()[depth].getClassName();
}
{code}
Now, one improvement possible using the Sun Reflection class (when possible) is
that we can get the caller class instead of just its name. That would bridge
over to the whole speed up for ClassLoaderContextSelector I mentioned on the
mailing list a few weeks ago.
I'll have to look through the code a bit more to see if there are many other
places that use the stack trace but don't scan over it. Or, it may be possible
that using the reflection version is faster than iterating over the stack
trace. I'll have to research more about this.
> Move caller class reflection utils to API
> -----------------------------------------
>
> Key: LOG4J2-809
> URL: https://issues.apache.org/jira/browse/LOG4J2-809
> Project: Log4j 2
> Issue Type: Task
> Components: API
> Affects Versions: 2.1
> Reporter: Matt Sicker
> Assignee: Matt Sicker
>
> In particular, ReflectiveCallerClassUtility should be moved into the API
> inside the util package. This will provide a nice alternative for making a
> new Throwable each time.
> For an idea on why this can be useful, run the ReflectionBenchmark in
> log4j-perf and note the differences. It's rather significant.
> Since this would go in the util package, it would be a non-public API. It
> would make sense for some very, very common utility classes like this to be
> in there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
