logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Williams <nicho...@nicholaswilliams.net>
Subject Re: Relfection.getCallerClass
Date Sat, 27 Jul 2013 19:16:03 GMT
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 <nicholas@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-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> 
>> -- 
>> Cheers,
>> Paul
> 


Mime
View raw message