It seems, that something has changed since JBoss EAP 7.4.10 regarding the binding of custom static modules.

Our service, that gets deployed in form of a WAR, contains a WEB-INF\lib\commons-io-2.11.0.jar. It does not use any entries in the jboss-deployment-structure.xml deployment descriptor to exclude or declare Apache commons-io as a module dependency.

If we deploy our WAR on a vanilla JBoss EAP v7.4.9, commons-io from inside our WAR is bound to our applications classpath.

Now another team that uses the same JBoss server added a custom static commons-io module to <EAP_HOME>/modules/org/apache/commons/io/main
using the same module name org.apache.commons.io as the already existing private JBoss commons-io module in the system directory:

module.xml:

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="org.apache.commons.io">
  <resources>
    <resource-root path="commons-io.jar"/>
  </resources>
</module> 

After a restart of the JBoss EAP v7.4.9 server, the binding of commons-io stays the same. As expected, it still binds commons-io from our WAR to our application.

But that behaviour changes, if we patch JBoss EAP to v7.4.10 or v7.4.11.

JBoss EAP v7.4.10+ binds commons-io from the custom static commons-io module instead the one delivered within our WAR. And even worse, if we try to exclude the undesired custom static commons-io module via the jboss-deployment-structure.xml deployment descriptor, it does not have any effect. After that JBoss still binds commons-io from the custom static module instead the one delivered within our WAR.