Bug 1116806 pulled in MODULES-192, which introduced a problem which can cause classloading failures of signed jars. The JarEntry.getCodeSigners() call was moved from after to before the input stream is read, and as per the documentation it MUST be after. This will cause null to be returned rather than the signing certificates the first time the resource loader is called for it. Usually the resource loader will only be called once for a class since it is cached after being loaded, so the only effect is the missing certificates. If however two threads concurrently load the same class, the second caller to the resource loader will get the certificates, resulting in a SecurityError since it does not match the lack of certificates for other classes. This has been seen occurring for the MS SQL JDBC driver (which is code-signed) when deployed as module.
Assume this is fixed by 1.3.5 modules upgrade
*** Bug 1154682 has been marked as a duplicate of this bug. ***
Martin, you seem to have encountered the same bug and therefore I suppose you will be more competent to verify this ;)
Verified with EAP 6.4.0.DR11 / JBoss Modules 1.3.6.Final