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.
