RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

[Joe Wang]

On 6/25/2012 9:34 AM, Paul Sandoz wrote:
> H Joe,
>
> I just focused on javax.xml.datatype and assumed the rest follows the same pattern :-)

Yeah, they are mostly similar, except Schema and XPath that do a little 
extra check.

>
> Like Alan i am still not sure about swallowing the ServiceConfigurationError. It enables something that did not work before so i guess it does not take anything away, if choose that this should be part of the spec then we should document it (as we should the dependence on TCCL).

Agree. It would be a compatibility concern.

>
> Also i notice that the previous code that explicitly loaded META-INF/service files deferred to SecuritySupport that wraps stuff in AccessController.doPrivileged blocks. Do we need to wrap the use of ServiceLoader in such blocks too? since ServiceLoader will internally call ClassLoader.getResources() and Thread.currentThread().getContextClassLoader().

Good catch, yes we do!  We're virtually delegating those calls to the 
ServiceLoader that could be blocked when security is on.

Joe

>
> Paul.
>
> On Jun 25, 2012, at 9:38 AM, Joe Wang wrote:
>
>> Hi all,
>>
>> Thanks for all the comments!
>>
>> I've updated the patch for the following recommended changes:
>> 1. ServiceConfigurationError instead of ConfigurationError
>> 2. Use factory class, class.forName section removed
>> 3. Use load method without specifying classloader
>> 4. To be clear on how the process handles exceptions, I've updated JavaDoc with the following:
>>
>>      * Uses the service-provider loading facilities, defined by the {@link java.util.ServiceLoader} class, to attempt
>>      * to locate and load an implementation of the service. In case multiple providers exist, the first
>>      * valid 3rd party provider should be returned; If there is no valid 3rd party provider,
>>      * the default implementation is returned if it is on the classpath or installed as a module.
>>      *
>>      * If ServiceConfigurationError is thrown, it is interpreted as an invalid provider is encountered.
>>      * The process shall continue the search until all are exhausted.
>>
>>      The JavaDoc is similar but slightly different for SchemaFactory and XPathFactory:
>>
>>      *<p>Uses the service-provider loading facilities, defined by the {@link java.util.ServiceLoader} class, to attempt
>>      * to locate and load an implementation of the service.
>>      *     Each potential service provider is required to implement the method:</p>
>>      *<pre>
>>      *        {@link #isSchemaLanguageSupported(String schemaLanguage)}
>>      *</pre>
>>      *     A service provider is deemed as valid if it supports the specified schema language.
>>      *
>>      *<p>
>>      * In case multiple providers exist, the first
>>      * valid 3rd party provider should be returned; If there is no valid 3rd party provider,
>>      * the default implementation is returned if it is on the classpath or installed as a module.
>>      *</p>
>>      * If ServiceConfigurationError is thrown, it is interpreted as an invalid provider is encountered.
>>      * The process shall continue the search until all are exhausted.
>>
>> We can continue discussing on a solution for the duplication of the classes. For this patch, if you agree, I'd like to check it in as it stands now and work out another patch for the duplicated classes once we have a solution.
>>
>> New webrev:
>> http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/
>>
>> Thanks,
>> Joe
>>
>>
>> On 6/22/2012 10:24 AM, Joe Wang wrote:
>>>
>>> On 6/22/2012 2:39 AM, Alan Bateman wrote:
>>>> On 21/06/2012 22:53, Joe Wang wrote:
>>>>> :
>>>>>
>>>>> We're not considering this change for jdk7 or older, i.e. I haven't thought about fixing 6975142.  For jdk8, it seems we have to live with the way it is in (2), a seemly incompatible behavior in backward compatible mode, although,  it is a very rare case (I regret to have taught or sent standalone jar files to those customers :)  ).
>>>> No, this isn't for jdk7 or older.
>>>>
>>>> I don't fully grok the issue in 6975142. That looks to me to be a case where the service provider implementation is including its own copy of the javax.xml.stream.* classes and this is the cause of the ClassCastException.
>>> Yes, it's GF packaged woodstox that included its own API packages.
>>>
>>> Joe
>>>
>>>> -Alan.