You should +1 it! :-) N
On Jul 27, 2013, at 4:35 PM, Paul Benedict wrote: > Nick, thank you for writing up that email. I hope it gets some attention. I > subscribe to that list so I will be eager to see what, if any, responses are > to your proposal. Good job. > > Paul > > > On Sat, Jul 27, 2013 at 2:16 PM, Nick Williams > <nicho...@nicholaswilliams.net> wrote: > Meanwhile, there's still the little problem that > sun.reflect.Reflection#getCallerClass(int) only exists in Sun JVMs and only > prior to Java 7u25. This is used in more than one place in Log4j 2 and not > consistently with a backup plan. I have an idea of what to do about that and > I'll work on that later this weekend. > > N > > > On Jul 27, 2013, at 2:03 PM, Nick Williams wrote: > >> 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 >> > > > > > -- > Cheers, > Paul
