JAXP default implementation and JDK-8152063

[David M. Lloyd]

On 03/21/2016 07:42 PM, huizhe wang wrote:
> On 3/21/2016 12:55 PM, David M. Lloyd wrote:
>> On 03/21/2016 01:38 PM, Alan Bateman wrote:
>>> On 21/03/2016 14:39, David M. Lloyd wrote:
>>>> This message is in reference to the aforementioned issue [1] that I've
>>>> requested my colleague Andrew Hughes to open on my behalf.
>>>>
>>>> As expressed in that issue, the means of specifying a JAXP default
>>>> provider (via system property which specifies a class name on the
>>>> application class path) is relatively antiquated at this point. It is
>>>> actually quite difficult for containers which ship their own JAXP
>>>> implementation to use the JDK APIs and, at the same time, ship their
>>>> own implementations, especially without polluting the class path of
>>>> applications which use JAXP.
>>> It would be good to expand a bit on what you are looking to do.
>>>
>>> Are you looking to change the system-wide default or are you looking for
>>> the container/app server to see a different default to the applications
>>> that it runs?
>>>
>>> As things currently stand then then default can be overridden by
>>> deploying the XML parser on the class path or as a service provider
>>> module on the module path. The JPMS requirements document includes a
>>> requirement for ordering service providers that isn't implemented yet.
>>> If/when that happens then it might help with part of this.
>>
>> I need to (optionally) change the system default globally, but from
>> code that is (probably) not on the module path of the base module
>> layer (in other words, it's coming from a layer which is loaded after
>> the boot module is run).  I can use the service provider logic to
>> always hook in a redirection layer (like we do today by way of the
>> system properties), however if we do this but there is/are no
>> overriding implementation(s) for one or more of these APIs, then
>> AFAICT it will fail with Jigsaw because we can't access the JDK's
>> default implementations (or even know what they are, barring
>> reflection & etc.), which pretty well puts us back to square one.
>
> 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).

-- 
- DML