RFR: 8013380 - Removal of stack walk to find resource bundle breaks Glassfish startup

[Mandy Chung]

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.

Thanks
Mandy

> 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.
>
> Thanks,
>     Jim
>
> On 04/30/2013 08:13 PM, Jim Gish wrote:
>> Here's an update:
>> http://cr.openjdk.java.net/~jgish/TestRB.3/ 
>> <http://cr.openjdk.java.net/%7Ejgish/TestRB.3/>
>>
>> Thanks,
>>     Jim
>>
>> 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/ 
>>>>> <http://cr.openjdk.java.net/%7Ejgish/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?
>>>>
>>> Yes
>>>> -Alan.
>>>
>>
>