JAXP default implementation and JDK-8152063
huizhe.wang at oracle.com
Thu Mar 24 23:35:47 UTC 2016
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.
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
> 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?
>> 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
>>>> 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
>>>> 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.
More information about the core-libs-dev