JAXP default implementation and JDK-8152063

huizhe wang huizhe.wang at oracle.com
Tue Mar 22 00:42:38 UTC 2016


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

Was it because the ServiceLoader mechanism was not meeting your 
requirement that you needed a proxy?

Thanks,
Joe

>
> An alternative might be to have some way to hook into global service 
> discovery at run time.  I don't have any ideas here that I can 
> concretely solve & code at this time however; the main appeal (to me) 
> of having global default setters is that this idea is relatively 
> simple to achieve and use.
>




More information about the core-libs-dev mailing list