JAXP default implementation and JDK-8152063
daniel.fuchs at oracle.com
Tue Mar 22 13:59:05 UTC 2016
On 22/03/16 13:53, David M. Lloyd wrote:
>> Am I understanding it correctly that you're pointing the system property
>> to a "proxy" as stated in JDK-8152063, not an actual implementation? So
>> it's sort of a provider-locating mechanism outside of jaxp, that locates
>> the actual implementation, and if it cannot find one, it attempts to
>> fall back to and directly instantiate the JDK's default. Is that why
>> "it will fail because we can't access the JDK's default implementations"?
>> Was it because the ServiceLoader mechanism was not meeting your
>> requirement that you needed a proxy?
> Right. Most user code using JAXP factories will just call e.g.
> XMLInputFactory.newFactory() with no arguments. So the ServiceLoader
> mechanism is fine when we want to allow the user to override the
> implementation with one they've bundled in their WAR or whatever. But
> if they do not do so, we are forced to ensure that another
> implementation is on the deployment class path. It's even worse in
> contexts where we cannot control what the TCCL is set to when the
> factory methods are called. There's just no practical way to ensure
> that our implementation is visible from every class loader. We can
> however "hack" our proxy implementations on to every class loader, and
> then later set the default factory class loader to use (which then just
> uses the same ServiceLoader-style load again, but from the class loader
> we choose).
If I understand well, what you need is to be able to
install a service provider that can create an instance
of the JDK default implementation in order to wrap it.
I assume such a service provider would have to be deployed
in the System ClassLoader - so that it could be shadowed
by whichever provider is declared in the context class
In order to create an instance of the JDK default implementation,
have you explored using the factory method that takes a
ClassLoader, and passing the extension class loader as
But maybe I'm misunderstanding the whole issue.
Would adding a method that resolves the concrete service
implementation against a Layer supplied by the caller be
of any help in your scenario?
More information about the core-libs-dev