BouncyCastle 1.51 loading in war on Wildfly 8.0

Question

Background

I am trying to use bouncy castle library to decrypt private keys in my war. Now I tested the code first in a standalone app and it worked

Answer 1

I. Combining the idea of Peter (@comment) and https://developer.jboss.org/thread/175395, create "your own bc version" with a custom name:

1. Create an 'my.bouncycastle' module in the following manner:

   • Under $JBOSS_HOME/modules, create directory 'my/bouncycastle/main'. Directory 'my' might not be there. ;)

   • Copy bcprov-[your-version].jar into my/bouncycastle/main

   • Create file 'bcprov-[your-version].jar.index' in my/bouncycastle/main, which is basically the output of a jar -tf command without the ".class" lines. (pipe&edit...)

     I put a blank line at the top because these .index files always seem to have one. I have attached this file as "bcprov-jdk16-1.46.jar.index".

   • Create a file called "module.xml", also in my/bouncycastle/main, which will point to the jar file and reference module "javax.api" as a dependency.

     I have attached this file as 'module.xml'. The module is complete.

2. Since I am deploying in an EAR file, I had to add a module dependency entry to my EAR's META-INF/jboss-deployment-structure.xml file, under the section, like so:

(the statement also applies to WAR files, when deployed on top-level, use the custom name as module reference)

    <deployment><dependencies><module name="my.bouncycastle" slot="main" export="true"/>  

3. Make certain that the ear's /lib directory does NOT contain bcprov-[your-version].jar. (actually II.)

Notes: The 'slot="main" and 'export="true" parameters are very important in the jboss-dependency-structure.xml file...

II. Adjust your maven dependency(ies) to:

<scope>provided</scope>

Note: Don't change the maven dependecy(ies group artifacts) to "my.bouncycastle", only the scope, this will ensure you a nice compile-time-behavior by the most IDE's AND will prevent your (maven-)war/jar/ear-plugin from packaging it into libs! (And which would be anyway the correct scope for a dependency like this.)