I've read all of these plus a few that are linked from them and haven't seen a concrete proposal for a fix that has been accepted. All the threads appear to have stopped so I don't know how I should consider the discussions "ongoing".
I should point out that besides the enhanced throwable converters ClassLoaderContextSelector also uses getCallerClass. It does that to determine the ClassLoader of the Class that obtained the Logger so that we can make sure it is associated with the LoggerContext associated with that ClassLoader (which means that when an app is un-deployed all of its Loggers are freed. Ralph On Jul 27, 2013, at 9:15 AM, Nick Williams wrote: > It was later pointed out to me that I was emailing the wrong list for this > kind of discussion. I've emailed the core libraries mailing list and several > thorough discussions have resulted. I made just the suggestion you point out > (get a stack trace from a Throwable that has Class objects in it) [1] [2] > [3]. Discussions are still ongoing and hopefully we can convince them to do > something. The more people we can have chiming in on these threads, the > better. > > Nick > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html > [2] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html, > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019098.html > [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018855.html > > On Jul 27, 2013, at 10:52 AM, Ralph Goers wrote: > >> Thanks Jörn, >> >> This was first reported to us in May in LOG4J2-245. Nick sent a message to >> the openjdk list at that time [1] but it seemed to be ignored. How would >> you propose we convince Oracle? To be honest, I would much prefer that I be >> able to get a stack trace from a Throwable that has the Class objects in it, >> instead of just the class names. >> >> Ralph >> >> >> >> [1] >> http://mail.openjdk.java.net/pipermail/java-se-8-spec-comments/2013-May/000014.html >> >> On Jul 26, 2013, at 2:43 AM, Jörn Huxhorn wrote: >> >>> Hi everyone. >>> >>> I wanted to inform you about the following Logback issues since their root >>> causes will also impact log4j: >>> >>> http://jira.qos.ch/browse/LOGBACK-885 >>> https://github.com/qos-ch/logback/pull/136 >>> >>> In short: >>> sun.reflect.Reflection.getCallerClass >>> - changed behavior in Java7u25 since the stack frames have changed. >>> http://bugs.sun.com/view_bug.do?bug_id=8016814 >>> - will throw an UnsupportedOperationException in upcoming Java7u40. >>> http://bugs.sun.com/view_bug.do?bug_id=8014925 >>> - will be removed in Java8 with no replacement. >>> http://bugs.sun.com/view_bug.do?bug_id=8020785 >>> >>> https://github.com/qos-ch/logback/pull/136 contains a way to get similar >>> informations but, unfortunately, it is 100x slower than >>> sun.reflect.Reflection.getCallerClass. >>> >>> http://bugs.sun.com/view_bug.do?bug_id=8014925 contains the following text: >>> "JEP-176 proposes to remove sun.reflect.Reflection.getCallerClass(int) that >>> has incompatibility concern since there are existing applications depending >>> on this private API such as Oracle Diagnostic Logging and jidesoft library >>> that breaks Oracle Primavera. >>> >>> The jdk part of JEP-176 has been backported to 7u25 but keep >>> sun.reflect.Reflection.getCallerClass(int) as the mitigration plan >>> (JDK-8014745) in 7u25. >>> >>> The following describes the transition plan to allow customers to migrate >>> their applications away from this private API: >>> 1. Disable sun.reflect.Reflection.getCallerClass(int) in 7u40 and provide a >>> flag to re-enable it >>> 2. Determine how this private API is being used and the use cases >>> 3. Remove this private API if there is no valid use case or there is a >>> proper replacement for it. Allow at least 2 CPU releases to allow customers >>> to make appropriate change. So the earliest for the removal is 7u55. If >>> there are valid use cases but no proper replacement, we may keep this >>> private API in jdk7u for longer." >>> I consider the use of this API in logging frameworks a very valid use case, >>> especially since the only replacements available would have severe impact >>> on the performance (other techniques like generating a Stacktrace via >>> Throwable are even slower than the SecurityManager workaround in the pull >>> request) - so we should probably all try to convince Oracle that a proper >>> replacement, ideally in a public API, is needed. >>> >>> Cheers, >>> Jörn. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>> >> >
