[jboss-dev] WarAnnotationMetaDataDeployer and AOP failures

[Ales Justin]

That needs to be re-written to use inputs/outputs.

On a funny note:
War deployers have a long history of hacks,
so only Remy is allowed to touch them. :-)

On more serious one:
I'll have a look at them after M2 (before M3),
and communicate the changes with Remy.

Kabir Khan wrote:
> 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
> 
> 
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>