JAXP default implementation and JDK-8152063

[David M. Lloyd]

This could also be fine, assuming that using the exception doesn't incur 
any kind of major performance degradation (e.g. I could make a subclass 
that suppresses fillInStackTrace(), and hopefully that will suffice to 
avoid any major costs).  It falls under the class of fixes that requires 
that our proxy still be in place though, which is unfortunate but 
acceptable (we've survived this long).

On 03/29/2016 03:27 AM, Peter Levart wrote:
> Hi,
>
> An easy way to make ServiceLoader loaded services decide at runtime for
> themselves if they want to be enabled or disabled is a little addition
> to their behavior. Suppose that a new exception type is defined:
> IgnoreServiceException. When this exception is thrown from the
> constructor of the service implementation, ServiceLoader could just
> ignore such service and behave as though it wasn't provided.
>
> Would that work?
>
> Regards, Peter
>
> On 03/28/2016 01:42 PM, 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