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(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
>>
>>
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Richard Opalka
ropalka(a)redhat.com
JBoss, by Red Hat
Office: +420 222 365 200
Mobile: +420 731 186 942