[jboss-dev] WarAnnotationMetaDataDeployer and AOP failures

[Ales Justin]

Why does AOPAnnotationMetaDataParserDeployer  have to be at PARSE stage?

Kabir Khan wrote:
> On 27 Jan 2010, at 14:26, Ales Justin wrote:
> 
>>> 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?)
> 
> The annotations are in classes in the .aop archive. They are parsed by AOPAnnotationMetaDataParserDeployer which should come after the SchemaResolverDeployer
> 
> public class AOPAnnotationMetaDataParserDeployer extends AbstractDeployer
> {
>    public AOPAnnotationMetaDataParserDeployer(int xmlParserOrder)
>    {
>       super.setOutput(AOPDeployment.class);
>       super.setStage(DeploymentStages.PARSE);
>       //Make this come after the AOPXMLMetaDataParserDeployer
>       super.setRelativeOrder(xmlParserOrder + 1);
>    }
> 
>    public void deploy(DeploymentUnit unit) throws DeploymentException
>    {
>       ....
>       AOPDeployment deployment = unit.getAttachment(AOPDeployment.class);
>       if (factories != null && factories.size() > 0)
>       {
>          if (deployment == null)
>          {
>             deployment = new AOPDeployment();
>             unit.addAttachment(AOPDeployment.class.getName(), deployment, AOPDeployment.class);
>          }
>          ...
>       }  
>    }
> 
> deployers.xml
>    <bean name="AOPXMLMetaDataParserDeployer" class="org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer">
>       <constructor>
>          <parameter>org.jboss.aop.microcontainer.beans.metadata.AOPDeployment</parameter>
>       </constructor>
>       <property name="suffix">-aop.xml</property>
>    </bean>
>    <bean name="AOPAnnotationMetaDataParserDeployer" class="org.jboss.aop.asintegration.jboss5.AOPAnnotationMetaDataParserDeployer">
>       <constructor>
>          <parameter><inject bean="AOPXMLMetaDataParserDeployer" property="relativeOrder"/></parameter>
>       </constructor>
>    </bean>
> 
> 
> 
>> 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.
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> 
> 
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>