How do I ignore/upgrade a module in JBoss Wildfly 9?

Question

I just downloaded Wildfly 9.0.0.CR2 with Java 7 on Mac 10.9.5. I notice by default, Wildfly 9 includes a bouncycastle module (modules/system/layers/base/org/bouncycastle/main/bcprov-jdk15on-1.52.jar) . I would like to install another bouncycastle module in Wildfly (bcprov-jdk16-1.46.jar). Is there a way I can disable the one that JBoss has included? When I tried to delete the module Jboss included (the modules/system/layers/base/org/bouncycastle/ folder), I get the error upon JBoss startup

08:36:19,086 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot:    org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
    at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
    at org.jboss.as.server.ServerService.boot(ServerService.java:350)
    at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:271)
    at java.lang.Thread.run(Thread.java:745)
Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module org.jboss.as.weld
    at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:155)
    at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:433)
    at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:144)
    at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:106)
    at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
    at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
    at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
    ... 3 more

score 0 · Answer 1 · edited May 23 '17 at 12:30

You might have a look at this discussion, it is almost the same thing you want to do (opposite direction w.r.t. versions): BouncyCastle 1.51 loading in war on Wildfly 8.0

The long and the short of it is, you can create a custom module (or, I think, another slot for the existing module?) and reference that one in your jboss-deployment-structure.xml instead of the default module wildfly is bringing with it.

If you don't want/need BC as a module, you could also just include it in the lib folder of your EAR/WAR and it will be loadable from there.

Our deployment structure looks essentially like this:

my.ear
  + lib/ <-- dependencies for multi-submodule deployment
  + META-INF/ <-- application.xml defines submodule(s) e.g. web.war, 
              <-- also jboss-deployment-structure.xml to include/export wildfly core modules for your EAR
  + web.war <-- our core deployment

And we include e.g. a different version of hibernate than in wildfly. I expect you can include a different BC version in your ear as well.

See also: https://docs.jboss.org/author/display/WFLY8/Class+Loading+in+WildFly

Custom module tutorial: http://middlewaremagic.com/jboss/?p=1933

Similar issue with resolution: https://developer.jboss.org/thread/175395

I added my own bouncycastle module and adjusted the jboss-deployment-structure.xml accordingly, but is there absolutely no chance JBoss is not reading its own bouncycastle module? Is there no way to disable it? It is not an option to package the bouncycastle JARs in my WEB-INF/lib directory. — Dave A, Jul 20 '15 at 21:48
The BC dep in wildfly was introduced with resteasy, https://issues.jboss.org/plugins/servlet/mobile#issue/WFLY-1570, but I think several other modules expect it to be there now (picketlink?) — sprockets, Jul 20 '15 at 22:07

score 0 · Answer 2 · answered Jul 30 '15 at 17:15

WildFly uses modular classloading and as such not everything is on classpath of every module. Deployment itself is just another module that gets extra dependencies based on what deployment descriptors tell server should be added.

When it comes to bouncycastle, there are modules that themselves require it, but that doesn't mean they will expose this dependency to your deployment.

There was a bug in 8.0 that caused that BC was exposed to user deployment in case when user deployment was using web services. This was fixed since than. Given that you use WildFly 9 that shouldn't a problem anymore.

As other suggested, you can create new module with different name or at least different slot name, which you can than include via your jboss-deployment-structure.xml

Just btw, bcprov-jdk16-1.46 is much older than what is provided in WildFly.

How do I ignore/upgrade a module in JBoss Wildfly 9?

2 Answers2