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

Jim Gish jim.gish at oracle.com
Wed May 15 21:19:52 UTC 2013

Please review http://cr.openjdk.java.net/~jgish/TestRB.7.1/ <http://cr.openjdk.java.net/%7Ejgish/TestRB.7.1/>

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. >>>

Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com

More information about the core-libs-dev mailing list