[jboss-dev] WarAnnotationMetaDataDeployer and AOP failures

Ales Justin ales.justin at gmail.com
Wed Jan 27 09:26:02 EST 2010


> 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.



More information about the jboss-development mailing list