Not sure if this is of any use, but I upgraded the WSS4j module to 1.6.3 by replacing the jar in the module folder for org.apaches.ws.security module. This seems to work.
Unfortunetly I need to downgrate to WSS4j 1.5.8 for me needs, but that doesn't work.
Ok, upgrading wss4j module to 1.6.3 works, but my dubt is about jboss class loading.
The documentation states:
Deployments in AS7 are also modules, and do not have access to classes that are defined in jars in the application server unless an explicit dependency on those classes is defined.
Even though in AS7 modules are isolated by default, as part of the deployment process some dependencies on modules defined by the application server are set up for you automatically.
Automatic dependencies can be excluded through the use of jboss-deployment-structure.xml.
"org.apache.santuario.xmlsec" isn't part of the list of automatic dependencies. And even if it was, why is jboss-deployment-structure.xml ignored?
This issue happens only for xmlsec module, all other modules aren't loaded, unless an explicit dependency on those modules is defined, according to the documentation.
Does xmlsec follow a different path? And, if so, why?
I am having a similar issue with removing resteasy-jackson-provider. I would like to use jettison's BadgerFish format and Jackson gets used instead because it is in the path. I have checked my war to be sure I am not includeing it by accedient and infact set the Maven scope for all of my RESTEasy dependencies to provided and told JBoss to exclude every RESTEasy module I found at https://docs.jboss.org/author/display/AS7/Implicit+module+dependencies+for+deployments in order to break the application and prove to myself that exclusions do work. Unfortunantly the application still work!!! (...still using Jackson, of course )
<!-- Make sub deployments isolated by default, so they cannot see each others classes without a Class-Path entry -->
<!-- This corresponds to the top level deployment. For a war this is the war's module, for an ear -->
<!-- This is the top level ear module, which contains all the classes in the EAR's lib folder -->
<!-- Exclusions allow you to prevent the server from automatically adding some dependencies -->
In this particular case I have a workaround in that I can just sprinkle @NoJackson everywhere in my Java code. But, this leaves me feeling like either exclusions simply do not work or I simply have no idea on how to make them work. I would love for whichever case to be resolved.
I really like the direction of the new classloader and love how fast everything is starting and deploying. Very nicely done. But, I like it much better if I can tell JBoss to back off on which classes it is prodiving so I can gain control back when I need it.
I would appreciate any help anyone can give me on this matter.
This may be a bit late to help you, but I ran into a similar issue as described in this thread: http://community.jboss.org/message/637818.
It ended up that the container's xmlsec library was loaded in because it was declared as a dependency of the javaee.api module, which IS an automatic dependency in a lot of cases.