On 3/31/2016 8:48 AM, mark.reinh...@oracle.com wrote:
2016/3/29 0:21:05 -0700, alan.bate...@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 FinderDele
2016/3/29 0:21:05 -0700, alan.bate...@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"
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 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 o
On 29/03/2016 10:55, Andrew Haley wrote:
:
I'm sure that's right. However, we are also running the risk of
breaking important use cases when JDK9 is released. We're going to
have to do a lot of work with developers to make sure that they can
still work with JDK9. The problem is that many devel
On 29/03/16 08:21, Alan Bateman wrote:
> 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-featur
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
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
proces
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.
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
alternati
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.
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
propertie
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-look
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 fai
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 ar
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() met
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
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
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
b) you do need JAXP's supporting using a
On 24/03/2016 14:57, David M. Lloyd wrote:
Does this mean that there will be a difference between upgradeable
modules and endorsed APIs under Jigsaw, or will all of JAXP be
fixed/locked to the platform including this API?
It's not clear that it's feasible to separate the endorsed APIs from
J
On 03/24/2016 11:26 AM, Alan Bateman wrote:
On 24/03/2016 16:09, David M. Lloyd wrote:
:
If the Layer of the module of the class calling the
newInstance/newFactory/etc. method could somehow be consulted in
service resolution decisions, that would definitely solve the problem
because our contai
On 24/03/2016 16:09, David M. Lloyd wrote:
:
If the Layer of the module of the class calling the
newInstance/newFactory/etc. method could somehow be consulted in
service resolution decisions, that would definitely solve the problem
because our container Layers could refer to the default impl
On 03/22/2016 08:59 AM, Daniel Fuchs wrote:
Would adding a method that resolves the concrete service
implementation against a Layer supplied by the caller be
of any help in your scenario?
I think I misunderstood this when you asked it. You mean let the Layer
have a hand in looking up the serv
On 03/24/2016 09:51 AM, Alan Bateman wrote:
On 24/03/2016 14:29, David M. Lloyd wrote:
Daniel, I have hacked together a way to use the system class loader
(which should be "good enough", I hope), but there is one further
problem: org.xml.sax.helpers.XMLReaderFactory does not have a factory
me
On 24/03/2016 14:29, David M. Lloyd wrote:
Daniel, I have hacked together a way to use the system class loader
(which should be "good enough", I hope), but there is one further
problem: org.xml.sax.helpers.XMLReaderFactory does not have a factory
method which accepts a class loader like the
On 24/03/16 15:29, David M. Lloyd wrote:
Daniel, I have hacked together a way to use the system class loader
(which should be "good enough", I hope), but there is one further
problem: org.xml.sax.helpers.XMLReaderFactory does not have a factory
method which accepts a class loader like the others
On 03/23/2016 07:12 AM, David M. Lloyd wrote:
On 03/22/2016 08:59 AM, Daniel Fuchs wrote:
Hi David,
On 22/03/16 13:53, David M. Lloyd wrote:
Am I understanding it correctly that you're pointing the system
property
to a "proxy" as stated in JDK-8152063, not an actual implementation? So
it's so
On 23/03/2016 12:12, David M. Lloyd wrote:
:
I wonder why JAXP is not considered to be upgradeable at this point?
MR 3 of JSR 206 (or JAXP 1.6 as it was called) in late 2013 announced
its end as a standalone technology. Going forward then the proposal is
that it be subsumed into the platfor
On 03/22/2016 08:59 AM, Daniel Fuchs wrote:
Hi David,
On 22/03/16 13:53, David M. Lloyd wrote:
Am I understanding it correctly that you're pointing the system property
to a "proxy" as stated in JDK-8152063, not an actual implementation? So
it's sort of a provider-locating mechanism outside of
Hi David,
On 22/03/16 13:53, David M. Lloyd wrote:
Am I understanding it correctly that you're pointing the system property
to a "proxy" as stated in JDK-8152063, not an actual implementation? So
it's sort of a provider-locating mechanism outside of jaxp, that locates
the actual implementation,
On 03/21/2016 07:42 PM, huizhe wang wrote:
On 3/21/2016 12:55 PM, David M. Lloyd wrote:
On 03/21/2016 01:38 PM, Alan Bateman wrote:
On 21/03/2016 14:39, David M. Lloyd wrote:
This message is in reference to the aforementioned issue [1] that I've
requested my colleague Andrew Hughes to open on
On 3/21/2016 12:55 PM, David M. Lloyd wrote:
On 03/21/2016 01:38 PM, Alan Bateman wrote:
On 21/03/2016 14:39, David M. Lloyd wrote:
This message is in reference to the aforementioned issue [1] that I've
requested my colleague Andrew Hughes to open on my behalf.
As expressed in that issue, th
On 03/21/2016 01:38 PM, Alan Bateman wrote:
On 21/03/2016 14:39, David M. Lloyd wrote:
This message is in reference to the aforementioned issue [1] that I've
requested my colleague Andrew Hughes to open on my behalf.
As expressed in that issue, the means of specifying a JAXP default
provider (
On 21/03/2016 14:39, David M. Lloyd wrote:
This message is in reference to the aforementioned issue [1] that I've
requested my colleague Andrew Hughes to open on my behalf.
As expressed in that issue, the means of specifying a JAXP default
provider (via system property which specifies a class
34 matches
Mail list logo
