the current jbossws-cxf integration allows users to provide their own spring configuration files and have the endpoint(s) specified in there be deployed using the jbossws customizations. One of the reasons for that is allowing cxf users to move their endpoints to jbossws while keeping all their configurations.
This currently implies having springs libs available in the big-ball-of-mud classloader / DefaultDomain. In the effort of preventing those libs from being visible to every user deployment even having nothing to do with WS, I've been reasoning on possible solutions (besides the obvious one that's removing them and expecting users to provide spring if they actually need to use that mean of configuring CXF).
One of the things I've tried is moving the "offending" libraries to the jbossws.deployers. Of course that's not enought, so I tried declaring an isolated classloader for the jbossws.deployer by providing a proper jboss-classloading.xml into the deployers/jbossws.deployer/META-INF
<classloading xmlns="urn:jboss:classloading:1.0" domain="JBossWSDeployerDomain" parent-domain="DefaultDomain" export-all="NON_EMPTY" import-all="true"> </classloading>
After having dealt with various classloading issues basically requiring to have jbossws-cxf integration, spring and cxf jars all together in the isolated classloader (due to to their dependencies/references), I've been able to deploy a test ws endpoint deployment coming with cxf ws-sec declaration through spring configuration file. Problems of course arise once the webapp generated for the ws endpoint by the deployer is first hit, as the classloader for that web app does not see anymore the classes from the jars in the isolated classloader.
We might probably end up considering completely different approaches to the jbossws-cxf configuration, but I'm wondering if someone here in the mean time has suggestions/idea on how we could keep support for spring configuration for now while limiting the consequences of that (perhaps some tricks with classloading configuration).