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

[Joe Wang]

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.