Java 9, JBoss Modules, JAXP Redirection

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Java 9, JBoss Modules, JAXP Redirection

David Lloyd-2
JBoss Modules has a redirection mechanism for JAXP that allows us to
override the default provider with one from a module, while still
allowing TCCL-based selection to occur.  Since Java 9, our
implementation violates the stricter reflection rules that are now in
place, meaning that JBoss Modules will probably stop working in a
future version.  We had hoped that Java 9 would have some useful way
to establish the default implementation of various JAXP factories, but
that never happened.  So I want to take the opportunity to review a
few mitigation options and get some feedback.

Option 1: Fix the redirection facility in Java 9

Java 9 offers a "newDefaultFactory()" method on most (maybe all) of
the JAXP factory classes, which always simply instantiates the system
provider of the given function.  Using this method should allow us to
bypass the now-disallowed reflection by switching all of the cached
Constructor<? extends T> fields with cached Supplier<T> fields, whose
implementation would either be a call to the appropriate
newDefaultFactory() or a service loader-style public Constructor call.

Pros:
• Less change
• We can still override the default JAXP implementation

Cons:
• Continue carrying around the baggage of the __redirected code
until/unless the JAXP spec is modified to allow setting the default
factories

Option 2: Stop using redirection in Java 9, "cold turkey"

We could delete these classes completely.  Instead of setting the
default JAXP implementation, we ensure that any modules using JAXP
have a services dependency on the implementation(s) corresponding to
those APIs, carefully monitoring TCCL setup and usage or ensuring that
the newFactory(xxx, getClass().getClassLoader()) form is always used,
depending on the situation.

Pros:
• No more dealing with redirection ever again
• While deployments generally use the newFactory() form, but
deployments also have TCCL set so that's not a problem
• One less source of bugs

Cons:
• It may be hard to be sure that we've done this 100% correctly in all
cases outside of deployments; the results could be weird mixed
implementations

Option 3: Use a dependency strategy

We could cause JBoss Modules to always include a "hidden" last
dependency on our chosen default JAXP implementation, which in turn
could be set up by a service loader configuration in the boot module.

Pros:
• Simpler than redirection

Cons:
• Due to the way JAXP works, we have to pollute the target module's
namespace with the implementation classes (though with redirection
we've already done that via __redirected classes)

So far Option 1 is (unfortunately) still looking the best to me,
overall.  Does anyone have any differing opinions on this?

--
- DML

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Java 9, JBoss Modules, JAXP Redirection

Tomaž Cerar-2

I am more in favor of option 2.

As long as we can make it work.

 

We already tried moving to JAXP completely quite recently,  but we did stumble upon few issues.

Mostly related to not fully compatible JAXP factory classes used by some of EE spec APIs

which haven’t been updated in a while.

One of such was SAAJ api https://github.com/jboss/jboss-saaj-api_spec

Along with few others in the webservices area.

 

If we can make it work going forward, it will probably be best benefit for us all.

 

I don’t think deployments themselves pose any big issues now days.

Bigger problems are libraries  / subsystems that we integrate. Especially some more arcane parts of EE stack.

 

--

tomaz

 

 

From: [hidden email]
Sent: torek, 05. december 2017 17:43
To: [hidden email]
Subject: [wildfly-dev] Java 9, JBoss Modules, JAXP Redirection

 

JBoss Modules has a redirection mechanism for JAXP that allows us to

override the default provider with one from a module, while still

allowing TCCL-based selection to occur.  Since Java 9, our

implementation violates the stricter reflection rules that are now in

place, meaning that JBoss Modules will probably stop working in a

future version.  We had hoped that Java 9 would have some useful way

to establish the default implementation of various JAXP factories, but

that never happened.  So I want to take the opportunity to review a

few mitigation options and get some feedback.

 

Option 1: Fix the redirection facility in Java 9

 

Java 9 offers a "newDefaultFactory()" method on most (maybe all) of

the JAXP factory classes, which always simply instantiates the system

provider of the given function.  Using this method should allow us to

bypass the now-disallowed reflection by switching all of the cached

Constructor<? extends T> fields with cached Supplier<T> fields, whose

implementation would either be a call to the appropriate

newDefaultFactory() or a service loader-style public Constructor call.

 

Pros:

• Less change

• We can still override the default JAXP implementation

 

Cons:

• Continue carrying around the baggage of the __redirected code

until/unless the JAXP spec is modified to allow setting the default

factories

 

Option 2: Stop using redirection in Java 9, "cold turkey"

 

We could delete these classes completely.  Instead of setting the

default JAXP implementation, we ensure that any modules using JAXP

have a services dependency on the implementation(s) corresponding to

those APIs, carefully monitoring TCCL setup and usage or ensuring that

the newFactory(xxx, getClass().getClassLoader()) form is always used,

depending on the situation.

 

Pros:

• No more dealing with redirection ever again

• While deployments generally use the newFactory() form, but

deployments also have TCCL set so that's not a problem

• One less source of bugs

 

Cons:

• It may be hard to be sure that we've done this 100% correctly in all

cases outside of deployments; the results could be weird mixed

implementations

 

Option 3: Use a dependency strategy

 

We could cause JBoss Modules to always include a "hidden" last

dependency on our chosen default JAXP implementation, which in turn

could be set up by a service loader configuration in the boot module.

 

Pros:

• Simpler than redirection

 

Cons:

• Due to the way JAXP works, we have to pollute the target module's

namespace with the implementation classes (though with redirection

we've already done that via __redirected classes)

 

So far Option 1 is (unfortunately) still looking the best to me,

overall.  Does anyone have any differing opinions on this?

 

--

- DML

 

_______________________________________________

wildfly-dev mailing list

[hidden email]

https://lists.jboss.org/mailman/listinfo/wildfly-dev

 


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Java 9, JBoss Modules, JAXP Redirection

Richard Opalka
In reply to this post by David Lloyd-2
Hello All,

   Yes, I have different opinion on this topic.

Options 1 and 3 are both introducing some
kind of magic into the JAXP usage picture.

Option 2 puts responsibilities where they
should be.

Since we should not predict JAXP API
users are incompetent I prefer Option 2.

Rio

On Tue, Dec 5, 2017 at 5:10 PM, David Lloyd <[hidden email]> wrote:

Option 1: Fix the redirection facility in Java 9

Option 2: Stop using redirection in Java 9, "cold turkey"

Option 3: Use a dependency strategy
 
So far Option 1 is (unfortunately) still looking the best to me,
overall.  Does anyone have any differing opinions on this?

--
- DML

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
--
Richard Opalka
Principal Software Engineer
Red Hat JBoss Middleware
Mobile: +420 731 186 942
E-mail: [hidden email]


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev