The code that sets CL to Module is not invoked in AbstractLevelClassLoaderSystemDeployer,
as you're bypassing it by providing your own CLF in AbstractClassLoaderDeployer.
You should bypass AEDeployer by providing proper filter in DU.
Similar to what we do here:
<bean name="DeploymentProvidedDUFilter" class="org.jboss.deployment.DeploymentProvidedDeploymentUnitFilter" /> <bean name="GenScanDeployer" class="org.jboss.deployers.vfs.plugins.annotations.FilteredAnnotationEnvironmentDeployer"> <property name="filter"> <bean class="org.jboss.deployment.ListDeploymentUnitFilter"> <property name="filters"> <list> <inject bean="DeploymentProvidedDUFilter" /> <inject bean="JBossMetaDataDUFilter"/> <inject bean="ScanningMetaDataDUFilter"/> <inject bean="JBossCustomDeployDUFilter"/> </list> </property> </bean> </property> </bean>
Thanks for the quick response. Which deployer should I bypass by providing a filter? Looking at the xml example it seems to be a filter per deployer. But the DeploymentProvidedDeploymentUnitFilter is attached to the DU. I don't get it. How should the filter be assigned to skip certain deployers? Can you give me another example?
OK, I get it. Since 5.1.0 it already configured to look for DeploymentUnitFilter attachments on the FilteredAnnotationEnvironmentDeployer. Makes sense. I'll give it try.