On 3/29/2016 12:21 AM, Alan Bateman wrote:
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:
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.
I'm not sure that it would be feasible to statically configure the VM
to use a module in a layer of modules that will get created sometime
later in the lifetime of the VM. Also this amounts to changing the
default implementation on the fly and something we should avoid
without deep consideration.
This option is similar to that previously suggested using Layer, except
it doesn't require a new method that takes a Layer. I thought a layer
would have already been created after the container had loaded its
modules. So, would the container pre-load its modules including the one
that might have been configured with a JAXP provider?
On the performance issue, this is a temporary issue with a new API
where we had to remove indexing in order to make progress. It
shouldn't impact anything and will sort it out once we get further on
a number of topics.
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.
No, not the JDK system class loader, but probably the container's system
or bootstrap loader. It belongs to the container, same as the "proxy"
David mentioned in the original email. JAXP would try to load it the
same way as it would with an implementation class.
I think the main thing is to tread carefully and it would be very easy
to introduce a troublesome mis-feature here.
Sure, we'd have some review circles to go through.
-Joe
-Alan.
