[jboss-dev] WarAnnotationMetaDataDeployer and AOP failures

[Richard Opalka]

On 01/27/2010 04:50 PM, 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.
>    
This is not true.

copy/paste from 
org.jboss.deployers.plugins.sort.DependenciesTopologicalDeployerSorter.Graph.sort()

public List<Deployer> sort()
{
   ...
   // ensure backward compatibility
   Collections.sort(roots, Ordered.COMPARATOR);
   ...
   while(!roots.isEmpty())
   {
     ...
     // ensure backward compatibility
     nextLevel = new TreeSet<Vertex>(Ordered.COMPARATOR);
     ...
   }
}

Backward compatibility is ensured with current deployers sorting 
algorithm, but we should remove it IMHO.
When https://jira.jboss.org/jira/browse/JBDEPLOY-233 will be fixed we 
will not support it any more.
I suggest to Kabir and everybody else relying on this fugly relative 
order feature to migrate to
input/output based deployers sorting.

The problem Kabir is seeing with current wrong deployers ordering is 
because someone touched inputs/outputs
of some deployers and this change affects him :(

Rio

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


-- 
Richard Opalka
ropalka at redhat.com
JBoss, by Red Hat

Office: +420 222 365 200
Mobile: +420 731 186 942