RFR: 8013380 - Removal of stack walk to find resource bundle breaks Glassfish startup
mandy.chung at oracle.com
Thu May 16 02:46:22 UTC 2013
On 5/15/2013 2:19 PM, Jim Gish wrote:
> Please review http://cr.openjdk.java.net/~jgish/TestRB.7.1/
Looks fine. This fix gets the Glassfish to run on jdk8 as an interim
fix while allowing us to investigate a proper solution for jdk8.
Daniel mentioned the performance overhead of Reflection.getCallerClass()
offline that does incur some overhead. Applications that create logger
with no resource bundle likely call Logger.getLogger(String name)
instead of Logger.getLogger(String name, String rbname). In other
words, when Logger.getLogger(name, rbname) is called, it's likely that
rbname is non-null. It might incur some performance overhead to
applications who resource bundle is visible to TCCL or system class
loader as Logger.getLogger(String, String) always obtains the immediate
caller but not used. In Glassfish and OSGi environment, there is no
performance issue since it has been doing the stack walk in the past. I
think it's fine as it is.
Nits: L1639, 1712 - better to align with the line above.
Thanks for extending the test to cover various cases.
> This is an update to the previous webrev. This is a temporary fix to
> workaround a regression that causes Glassfish 4.0 to fail to startup.
> A proper fix will be investigated.
> On 04/30/2013 08:13 PM, Jim Gish wrote:
>> Here's an update:
>> On 04/30/2013 05:10 PM, Jim Gish wrote:
>>> On 04/30/2013 04:29 PM, Alan Bateman wrote:
>>>> On 30/04/2013 17:48, Jim Gish wrote:
>>>>> Please review http://cr.openjdk.java.net/~jgish/TestRB.2/
>>>>> This fixes a regression caused by the removal of the search of the
>>>>> call stack for resource bundles by java.util.logging. We have
>>>>> added a single-level search up the stack, i.e. just the immediate
>>>>> caller's ClassLoader, as an additional alternative to the
>>>>> specified method of using the thread context classloader if set
>>>>> and the system classloader if the TCCL is not set. This is
>>>>> intended to handle cases such as Glassfish or other OSGi-based
>>>>> apps/3rd-party libs for which setting the TCCL is not feasible.
>>>> It's unfortunate that the stack walk was masking this issue. Are
>>>> you planning an update to the javadoc to reconcile the spec vs.
>>>> impl difference?
More information about the core-libs-dev