[jboss-jira] [JBoss JIRA] (WFCORE-3522) Module dependency order for a deployment is wrong

[David Lloyd (JIRA)]

    [ https://issues.jboss.org/browse/WFCORE-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521103#comment-13521103 ] 

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/org/jboss/as/server/deployment/module/ModuleSpecProcessor.java#L241-L250
> 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.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)