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.
