I've found out that if I specify an ear file name as domain name in jboss-classloading-domain.xml then I see two classloaders in JMX view:
domain: "jboss.j2ee:extension=LoaderRepository,service=EARDeployment,url='myapp.ear'" - the default one created by ear deployer, with parent policy: "AFTER_BUT_JAVA_BEFORE" and parent domain "DefaultDomain"
domain: "myapp.ear" - created from jboss-classloading-domain.xml, with parent policy: "(before=EXCLUDE [org.hibernate.validator] after=)" and no parent domain (null).
So it looks like I'll have to either add jboss-classloading.xml to change the domain name to the same valuse which is in jboss-classloading-domain.xml or modify jboss-classloading-domain.xml to use the default one.
I quickly tried both but it broke the app - it couldn't load javax.servlet.http.HttpServlet (using negated recursive package filter for org.hibernate.validator as before-filter). With some other filter it couldn't start for other reasons so I'll try figure out a bit more about what actually happens..
Ah, another thing I missed -- EARClassLoaderDeployer. ;-(
Same issue as WebCLDeployer, it also sets some defaults, if no CLMetaData exists.
Let me check what gets used if you don't define any parent-domain in jb-cl-domain.xml.
Also I noticed that war classloaders don't show up any parent domain (null).
How do you see this?
Didn't we fix this with explicit jb-cl.xml in each of the wars? (until WebCLDeployer is fixed)
So do you think that NothingClassFilter combined with RecursivePackageFilter (the same way as NegatingClassFilter) would do the desired blocking?
If you use NothingFilter then there is nothing to combine. ;-)