JAXP default implementation and JDK-8152063
huizhe.wang at oracle.com
Thu Mar 31 16:33:33 UTC 2016
On 3/31/2016 8:48 AM, mark.reinhold at oracle.com wrote:
> 2016/3/29 0:21:05 -0700, alan.bateman at oracle.com:
>> On 28/03/2016 23:46, huizhe wang wrote:
>>> Thanks David. So I understand the dynamic nature of the server
>>> configuration. There maybe two options to solve it:
>>> 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 devil is in the detail of course. You haven't said if the
>> FinderDelegate implementation has to be visible via the system class loader.
>> I think the main thing is to tread carefully and it would be very easy
>> to introduce a troublesome mis-feature here.
> This has been an interesting discussion. Now that I understand David's
> scenario better, I suspect this is just one instance of a more general
> problem, and in fact one that should be solved by a module-system
> requirement we previously recorded but have not yet addressed:
> Let's please not add yet more complexity to JAXP, if we can help it.
Ok. So it looks like we've presented an use case.
> - Mark
More information about the core-libs-dev