Exclude implicit modules in jboss-deployment-structure.xml

[white_crow]

Hello there

We have a web application (WAR) running on Wildfly 10.0.0 FINAL. We're currently facing some library conflicts: Because we provide many different features (like REST, web service security, JAXB and Jackson), we very carefully need to put together our dependencies, since they have lot of dependencies in common. That's why we want to pack many of the stuff with our WAR deployment and not use installed versions on Wildfly.

Reading the documentation, I clearly understand that there are some implicit modules (Implicit module dependencies for deployments - WildFly 10 - Project Documentation Editor) which are either always loaded or only if a certain precondition is met. Most of them are stuff from the JavaEE API. The implicit modules are basically listed in the javaee.api module ([WILDFLY-FOLDER]/modules/system/layers/base/javaee/api/main/module.xml). Further, it is mentioned in the docu, that one has full control over modules being loaded by the classloader - by either defining an explicit include of a module or by an explicit exclude of any implicit module or subsystem.

Long story short: We are now trying to exclude some of the implicit modules being loaded by the classloader, however, it seems not to work... Are we doing something wrong here, or is this a known bug? Because I've seen many other threads in this forum with the same problem, but none got really an answer:

Re: Exclude RESTeasy from deployment in JBoss EAP 6.4.9

Module not excluded although specified in jboss-deployment-structure.xml

common libraries, modules & implicit dependency

Is it possible to use jboss-deployment-structure.xml to exclude buggy transitive dependency from module I depend on (and replace it ?)

As an example, we have something like this in our jboss-deployment-structure.xml:

<jboss-deployment-structure>

    <deployment>

        <exclude-subsystems>

            <subsystem name="webservices"/>

            <subsystem name="jaxrs"/>

        </exclude-subsystems>

        <exclusions>

            <module name="javax.jws.api"/>

            <module name="javax.xml.ws.api"/>

            <module name="javax.ws.rs.api"/>

            ....

Excluding the subsystem somehow does a change. However, the exclusions of modules seem to be ignored. We could verify this by using the -verbose:class JVM option: Comparing the outputs once without exclusions an once with exclusions in place -> no change at all!

One thought I had - but not tried yet - will it maybe make a difference, if deploying instead of just a WAR, an the WAR inside an EAR? So one could work with sub-deployments in the jboss-deployment-structure.xml

This is quite frustrating, because we really like the idea of modules. But if this does not work, we would have to patch some existing modules on Wildfly, which we really trying to avoid by all means...

Thanks a lot,

Cheers

[jamezp]

If you're excluding Java EE API's is there a reason you're using a Java EE container? Have you maybe tried using the WildFly Servlet Distribution which only contains the servlet API's?

--

James R. Perkins

[white_crow]

Hi James

Thanks for your answer. We don't want to exclude all of them: We still require a lot of features like CDI, EJB, JTA, JPA etc.

And even we would move to another container, the problem still exits: I think many people get quite confused when trying something as described in the documentation but isn't working. If it is a known issue it should be stated in the documentation or a ticket should be opened.

Thanks

[ctomc]

No need to exclude javaee.api anymore as it this behavior was changed in WildFly 9 (or maybe 8), as it was bit problematic in EAP6

This way subsystems that are in charge of certain EE functionality add their own spec deps when activated.

so excluding certain subsystem should be enough.

but do be careful with how you configure exclusions as behavior is different for wars vs ears, where you need to put the sub-deployments config as well.

when it comes to debugging classloading, i would recommend setting logging of org.jboss.modules to TRACE, this way you will see much more in detail what is going on and from where classes are coming.