Re: [jboss-dev] WarAnnotationMetaDataDeployer and AOP failures

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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development >