By "ongoing" I meant that nothing had been agreed on yet. I've been meaning to bring it back up and jump-start negotiations, and I'll do that now.
Nick On Jul 27, 2013, at 12:40 PM, Ralph Goers wrote: > 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 >>>> >>> >> >
