I think I found out why this is happening.
When AOPXMLMetaDataParserDeployer (SchemaResolverDeployer) is triggered
to process the .aop unit, there is already a metadata previously created
for the annotated binding. Take a look at the beginning of method
AbstractParsingDeployerWithOutput.createMetaData:
protected void createMetaData(DeploymentUnit unit, Set<String> names,
String suffix, String key) throws DeploymentException
{
// First see whether it already exists
T result = getMetaData(unit, key);
if (result != null && allowsReparse() == false)
return;
// Create it
....
So, result is not null (it contains the annotated binding) and
allowsReparse returns false, thus preventing the deployer from finding
META-INF/aop.xml.
Where does the previous metadata come from?
(OK, annotation binding, but where is this annotation binding?)
Either this deployer kicks in at the wrong stage,
or you're didn't consider any metadata merging.
I compared this with the behavior of deploying aop-scopedear1.aop.
This
file contains no aspect annotations and, hence,
AOPXMLMetaDataParserDeployer gets a null result at the beginning of
createMetaData and is able to find META-INF/jboss-aop.xml file.
We are not seeing the same failure for aop-scoped2 because the aop.xml
file is outside META-INF and, for what I saw during debugging, this is
treated as a child unit. So there is no searching for
META-INF/jboss-aop.xml involved.
Yes, xml/config files outside metadata locations (META-INF, ...) are
treated as subdeployments.