[jboss-dev] WarAnnotationMetaDataDeployer and AOP failures

Kabir Khan kabir.khan at jboss.com
Wed Jan 27 11:16:22 EST 2010


When modifying tomcat/src/resources/war-deployers-jboss-beans.xml I noticed that there was loads of use of relative order in the existing deployers there
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





More information about the jboss-development mailing list