]
David Lloyd commented on WFCORE-3522:
-------------------------------------
This is another example of why parent-first class loading is always wrong. We should
instead be excluding the set of packages in deployment resource loaders that are found in
dependencies that we want to flag (along with a hefty warning or error message).
Module dependency order for a deployment is wrong
-------------------------------------------------
Key: WFCORE-3522
URL:
https://issues.jboss.org/browse/WFCORE-3522
Project: WildFly Core
Issue Type: Bug
Affects Versions: 3.0.8.Final
Reporter: Ken Finnigan
Priority: Blocker
Within WildFly Swarm we need the ability to override the
`javax.ws.rs.client.ClientBuilder` service file for a deployment to provide custom
handling for implementing Eclipse MicroProfile.
With a service file present in the deployment, the existing RESTEasy service file is
always found first because the deployment module is added as a dependency after other non
local dependencies. See
https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
After discussing with [~dmlloyd] on IRC, he agreed this was a bug and a better solution
was for the deployment's dependency to always be first if `isLocalLast()` is false,
and instead remove any spec packages that might be present on the deployment path
instead.
He explained the purpose of this ordering was to prevent a user deploying
`javax.servlet.api` and breaking things, but it appears this can be achieved by
alternative methods.