RFR: 8013380 - Removal of stack walk to find resource bundle breaks Glassfish startup (original) (raw)

Daniel Fuchs daniel.fuchs at oracle.com
Thu May 16 16:50:27 UTC 2013

Done

-- daniel

On 5/16/13 5:20 PM, Jim Gish wrote:

Thanks.

Daniel -- could you please push http://cr.openjdk.java.net/~jgish/TestRB.7.2/ <http://cr.openjdk.java.net/%7Ejgish/TestRB.7.2/> ? Jim On 05/16/2013 08:13 AM, Alan Bateman wrote: On 16/05/2013 03:46, Mandy Chung wrote:

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 looks okay to me too and I agree with Mandy's comment about thinking of this as a fix for the short-term. More work will be required to figure out what the right thing to do is and maybe the methods that take a resource bundle name needed to be deprecated in favor of new methods. -Alan

More information about the core-libs-dev mailing list