[jira] [Created] (LOG4J2-809) Move caller class reflection utils to API

[Matt Sicker (JIRA)]

Matt Sicker created LOG4J2-809:
----------------------------------

Summary: 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)

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-809:
------------------------------------

{quote}This will provide a nice alternative for making a new Throwable each time.{quote}
Each time what?

Post by Matt Sicker (JIRA)
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)

[Matt Sicker (JIRA)]

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

Post by Matt Sicker (JIRA)
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)

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-809:
------------------------------------

The real problem here is that this lookup may be done twice. The first time is in LogManager if a class wasn't passed. The second time is to get the caller's actual Class object in ClassLoaderContextSelector. I suppose speeding this up would help, but only for calls where we aren't passed a logger name.

FWIW, I've not seen any mention of the JDK adding a new method in Java 9 as they had said.

Post by Matt Sicker (JIRA)
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)

[Matt Sicker (JIRA)]

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

Matt Sicker commented on LOG4J2-809:
------------------------------------

Post by Matt Sicker (JIRA)
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)

[Matt Sicker (JIRA)]

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

Matt Sicker commented on LOG4J2-809:
------------------------------------

And it's still [in the JDK9 code as of now|http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/java.base/share/classes/sun/reflect/Reflection.java].

Post by Matt Sicker (JIRA)
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)

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-809:
------------------------------------

The proposal looks very good but I am not sure it was ever submitted or accepted.

Post by Matt Sicker (JIRA)
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)

[Matt Sicker (JIRA)]

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

Matt Sicker commented on LOG4J2-809:
------------------------------------

Added a change in the OSGi metadata to allow for use of sun.reflect.

Post by Matt Sicker (JIRA)
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)

[Matt Sicker (JIRA)]

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

Matt Sicker commented on LOG4J2-809:
------------------------------------

The part I'm working on right now is the fallback version that uses a Throwable stack trace. I've got an equivalent version that behaves the same as the internal API when run on OpenJDK, but I still need to find out what packages or class names to expect in alternative JVMs that are equivalent to the {{sun.reflect}} classes (which all get ignored in the stack frame walk). It's too bad the function {{JVM_GetCallerClass(JNIEnv* env, int depth)}} in {{jvm.h}} is probably not part of the standard JNI functionality, or else we could just bundle a native alternative.

Post by Matt Sicker (JIRA)
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)

[Matt Sicker (JIRA)]

[ https://issues.apache.org/jira/browse/LOG4J2-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Sicker resolved LOG4J2-809.
--------------------------------
Resolution: Implemented

Current fully functional implementation in the LOG4J2-809 branch. Would like some review before merging to master. It's possible that one or two of the methods in it could be split back into log4j-core only.

Post by Matt Sicker (JIRA)
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)

[Matt Sicker (JIRA)]

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

Matt Sicker commented on LOG4J2-809:
------------------------------------

I've also updated LogManager to take advantage of this class as well as to use the ClassLoader of the Class provided to LogManager. This should help speed up ClassLoaderContextSelector as well as make it work more correctly in Java EE environments. In fact, should this idea work well, then the JNDI ContextSelector won't be so important anymore!

Post by Matt Sicker (JIRA)
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)

[Matt Sicker (JIRA)]

[ https://issues.apache.org/jira/browse/LOG4J2-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Sicker closed LOG4J2-809.
------------------------------

Pushed to master.

Post by Matt Sicker (JIRA)
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)