JAXP default implementation and JDK-8152063

[huizhe wang]

Right, that sounds like what I thought you would want: an additional 
step in the factory-lookup process to try locating a provider through 
the Layer of the caller if TCCL fails.  I think the assumption in the 
previous discussion was that a new method would be introduced to take a 
Layer as an argument.

-Joe

On 3/24/2016 3:36 PM, David M. Lloyd wrote:
> This is all for the case where the user is calling e.g. 
> javax.xml.stream.XMLInputFactory#newFactory() with no arguments. We 
> need some way to choose a specific non-JDK default implementation when 
> there is no service loader info on the TCCL. Using the Layer of the 
> caller of the newFactory() method would be an ideal solution from our 
> perspective.
>
> On 03/24/2016 05:18 PM, huizhe wang wrote:
>> So specifying Layer is preferred solution. If a new method is needed
>> however, (similar situation to using the method with ClassLoader), that
>> would mean your users' applications are required to adapt to the new
>> API. Would you expect that would happen or would you still have existing
>> applications that can not be updated?
>>
>> -Joe
>>
>> On 3/24/2016 2:02 PM, David M. Lloyd wrote:
>>> On 03/24/2016 03:54 PM, huizhe wang wrote:
>>>> In this discussion so far,
>>>>
>>>> a) I see that you seemed to have successfully used the method with a
>>>> class loader as Daniel suggested.  I assume that solved the issue
>>>> reported in JDK-8152063. Am I right, that you no longer have issue 
>>>> with
>>>> using a proxy? Or
>>>
>>> No, not solved yet, just in the process of prototyping but ran into a
>>> road block with XMLReaderFactory.
>>>
>>>> b) you do need JAXP's supporting using a Layer as the context in order
>>>> to solve your issue completely?
>>>
>>> I think this should be considered the best solution to the problem.
>>>
>>>> c) On org.xml.sax.helpers.XMLReaderFactory, as Alan and Daniel 
>>>> said, yes
>>>> I'm working with the SAX project to hopefully get a new release out 
>>>> that
>>>> would conform to the ServiceLoader spec.  I'm also suggesting a new
>>>> method that takes a ClassLoader that would be useful if (a) worked
>>>> for you.
>>>
>>> We have some more testing to do before I can say whether this works or
>>> does not work.  But either way it is a rather non-optimal solution,
>>> and if I can avoid using a proxy layer, I would much prefer to do so.
>>>
>>> Thanks for your response.
>>>
>>
>