On 11/04/2016 16:57, Jochen Theodorou wrote:
:
Can it be registered via registerDriver? That actually made me wonder
why exactly we require the system loader here in the first place.
Part of the problem is DriverManager#getConnection, which is
@CallerSensitive. So if I want to get a connection from an arbitrary
loader, it has to be the same loader, that registered the driver, or a
higher one. Here getConnection is done from library code, with a
different loader. So it cannot work that way... sigh... not reliably.
I need to dig into the history of JDBC to fully understand why this is
so. Clearly the original JDBC API used a global registry of JDBC drivers
and this falls apart when there are several applications running in the
VM, esp. as each might bundle its own drivers and have a different view
of the available drivers. In Java EE applications then the TCCL is often
used to identify the application and it's not clear why this wasn't done
here.
:
And then of course there is the problem of XML parser being loaded
dynamically. You get effects like this:
https://bugs.openjdk.java.net/browse/JDK-8015099, and we too had
already a load of fun with xerces being part of the distribution and
the violation of classloading constraints. All that gets worse, if you
want to "download" something like xpp3 from the web in your
application and then use it directly.
This is very fishy too as this is not how JAXP is intended to work. If
there are two web applications in the same VM then they shouldn't
interfere. The only obvious interference that I can see in the bug
report is the "workaround" as that changes VM wide default. Someone
needs to dig into it but it may be that the first app is also setting
org.xml.sax.driver to change the VM-wide default.
:
that would then be:
org.codehaus.groovy.runtime.InterfaceConversionTest >
testDefaultInterfaceMethodCallOnProxy FAILED
java.lang.AssertionError: java.util.Comparator/2
at
java.lang.invoke.MethodHandles$Lookup.toString(java.base@9-ea/MethodHandles.java:792)
at java.lang.String.valueOf(java.base@9-ea/String.java:2806)
at
java.lang.StringBuilder.append(java.base@9-ea/StringBuilder.java:135)
at
java.lang.invoke.MemberName.makeAccessException(java.base@9-ea/MemberName.java:867)
at
java.lang.invoke.MethodHandles$Lookup.checkAccess(java.base@9-ea/MethodHandles.java:1642)
at
java.lang.invoke.MethodHandles$Lookup.checkMethod(java.base@9-ea/MethodHandles.java:1582)
at
java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(java.base@9-ea/MethodHandles.java:1731)
at
java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(java.base@9-ea/MethodHandles.java:1725)
at
java.lang.invoke.MethodHandles$Lookup.unreflectSpecial(java.base@9-ea/MethodHandles.java:1336)
at
org.codehaus.groovy.vmplugin.v7.Java7.getInvokeSpecialHandle(Java7.java:96)
at
org.codehaus.groovy.runtime.ConversionHandler.invoke(ConversionHandler.java:109)
at com.sun.proxy.$Proxy47.reversed(Unknown Source)
at java_util_Comparator$reversed$0.call(Unknown Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
at
org.codehaus.groovy.runtime.InterfaceConversionTest.testDefaultInterfaceMethodCallOnProxy(InterfaceConversionTest.groovy:52)
but if I see the trace correctly, this is already due to a failed
access check and just a secondary error, or wrong?
I suspect there is a bug here as I think how it is possible to have a
Lookup with this lookup mode. Are you able to establish where this
Lookup is created and if it indeed created with only the PRIVATE mode set.
-Alan
