I have revived all the previous threads with a consolidated thread proposing an API that solves all of the needs that everyone has expressed. Chime-ins/+1s would be appreciated. Cross your fingers.
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019334.html Nick On Jul 27, 2013, at 1:46 PM, Paul Benedict wrote: > I bought this up a couple of times too. Here's my latest: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019118.html > > I jumped into the discussion because of @CallerSensitive. They were talking > about getCallerClass() and I proposed they expose that as a public API. I see > no reason why it shouldn't -- it is certainly useful in several situations. > However, no Oracle employee ever responded to me. > > Paul > > > On Sat, Jul 27, 2013 at 12:53 PM, Nick Williams > <nicho...@nicholaswilliams.net> wrote: > 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 >>>>> >>>> >>> >> > > > > > -- > Cheers, > Paul
