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: David Lloyd
Sent: torek, 05. december 2017 17:43
To: WildFly Dev
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

wildfly-dev@lists.jboss.org

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