JAXP default implementation and JDK-8152063

[Daniel Fuchs]

Hi David,

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"?
>
> Correct.
>
>> 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
loader.

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
parameter?

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?

best regards,

-- daniel