JAXP default implementation and JDK-8152063

[David M. Lloyd]

On 03/22/2016 08:59 AM, Daniel Fuchs wrote:
> 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?

I can definitely try this out to see if we can use it.  How can I get 
the extension class loader though?  Weird as it sounds, I haven't found 
any idioms which can do so reliably (and it has to work across JVMs as 
well).

Will module readability/exports interfere with this?

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

Probably not in this case that I can see, though that might be a useful 
feature in any event.

I wonder why JAXP is not considered to be upgradeable at this point?

-- 
- DML