JAXP default implementation and JDK-8152063

[huizhe wang]

Awesome. I'll look into getting a spec change approved.

Best,
Joe

On 3/28/2016 6:24 PM, David M. Lloyd wrote:
> I think that either of these options would work great for us.
>
> On 03/28/2016 05:46 PM, huizhe wang wrote:
>> Thanks David.  So I understand the dynamic nature of the server
>> configuration. There maybe two options to solve it:
>>
>> 1) Add a system property to point to a Layer in order to find an
>> alternative-system-default. This will add a new step to the JAXP process
>> after the current ServiceLoader process.  I saw that you had concern
>> over the performance of searching a provider among all modules in a 
>> Layer.
>>
>> or
>>
>> 2) Add a new type FinderDelegate for processes such as the "proxy" in
>> your case to implement. If the FinderDelegate process fails to locate a
>> provider, it would signal the jaxp process (by returning null) to fall
>> back to the JDK-default implementation. In other words, when the system
>> property points to a FinderDelegate, the 4-step JAXP process is reduced
>> to two: delegate the process to the FinderDelegate, and fall back to the
>> system default implementation.
>>
>>     The benefit of this approach is that container developers are
>> allowed complete flexibility to define the process within their
>> environment, thus probably more adaptable to any changes.
>>
>> -Joe
>>
>> On 3/28/2016 4:42 AM, David M. Lloyd wrote:
>>> The reason is because we use a single boot path but we don't know at
>>> the time of boot whether or not we will have a JAXP provider, nor
>>> where it will come from; that is up to the server configuration that
>>> we end up running.  With the system properties approach we can just
>>> clear all the properties, but if we use ServiceLoader then we can't
>>> switch it on and off on demand.
>>>
>>> On 03/26/2016 04:57 PM, huizhe wang wrote:
>>>> Going back to the original issue a bit, if you don't mind.
>>>>
>>>> The issue was that JBoss wished to configure its own default providers
>>>> for certain JAXP-defined services. What you've been doing until now 
>>>> was
>>>> to point the system property to a proxy, which, in essence, took over
>>>> the JAXP provider-lookup process, and served as a factory finder 
>>>> outside
>>>> of JAXP.  "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".
>>>>
>>>> So the question is, why did you have to override the JAXP process for
>>>> the services that you don't have an AppServer-level provider (
>>>> "overriding implementation(s)" )?
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>> On 3/25/2016 5:53 AM, David M. Lloyd wrote:
>>>>> OK, so disappointment again. :) Thanks for responding; the search
>>>>> continues.
>>>>>
>>>>> On 03/24/2016 06:35 PM, huizhe wang wrote:
>>>>>> 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.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>