[jboss-dev] WarAnnotationMetaDataDeployer and AOP failures

[Ales Justin]

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