[jboss-dev] WarAnnotationMetaDataDeployer and AOP failures

[Kabir Khan]

Moving it to POST_PARSE fixes the three failure we were seeing, but introduces a new failure. If m2eclipse finishes updating maven dependencies before Sunday I'll try to debug why.

Does m2eclipse take ages to do its stuff for every pom update for everybody else, or is there something wrong with my setup? The last time it took 20 minutes
On 27 Jan 2010, at 15:50, Ales Justin wrote:

> Looking at the code, I don't see a reason why it cannot be at POST_PARSE.
> 
> Another thing we can notice from this issue is that deployers ordering 
> has changed -- it seems we (already) no longer use relative order for 
> ordering.
> 
> So, be alert on similar issues, as I've already found few things related 
> to bad/insufficient info of inputs/outputs in deployers.
> (the alt-dd issue was a result of this)
> 
> Ales Justin wrote:
>> 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
>>> 
>> 
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development