JAXP default implementation and JDK-8152063

David M. Lloyd david.lloyd at redhat.com
Tue Mar 29 01:24:01 UTC 2016


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.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-- 
- DML



More information about the core-libs-dev mailing list