KernelDeploymentDeployer and annotations in MDR

[starksm64]

Shouldn't the KernelDeploymentDeployer be loading the KernelDeployment annotations into the deployment MetaData?

[alesj]

The annotations merge is done here:
- http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/kernel/src/main/java/org/jboss/kernel/plugins/deployment/AbstractKernelDeployment.java

[adrian.brock]

But wouldn't it make more sense if the deployment annotations
went into the DEPLOYMENT scope rather than the INSTANCE scope?

i.e. there is no merge, just the normal overrides by scope

This would also allow some other deployer to modify them.

I didn't remember adding annotations to kernel deployments :-)
so I went back to the original change
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas?view=rev&revision=60491
and from the date of that located the forum thread
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=100349

The issue appears to be that for the plain deployment,
we don't necessarily have the classloader from which we can
create the annotations. e.g.

<deployment>
 <classloader><inject name="BeanConstructedLaterOrInThisFile"></classloader>
 <annotation>@from.that.Classloader</annotation>
</deployment>

This could in principle also apply to the VDF,
but more often than not we can use the DeploymentUnit's classloader.

[starksm64]

The current issue is that I do not see a deployment level annotation such as the following:

<deployment xmlns="urn:jboss:bean-deployer:2.0">

<annotation>@org.jboss.managed.api.annotation.ManagementDeployment(description="JBossSX Security Beans")</annotation>
...

when creating the MangedObject for the KernelDeployment attachment in the KernelDeployment's DeplomentUnit MetaData. This annotation should not be pushed down to the component BeanMetaData.

[starksm64]

The issue appears to be that for the plain deployment,
we don't necessarily have the classloader from which we can
create the annotations. e.g.

<deployment>
 <classloader><inject name="BeanConstructedLaterOrInThisFile"></classloader>
 <annotation>@from.that.Classloader</annotation>
</deployment>

It could create a static MetaDataLoader if the class loader was not a bean or a bean that was available, otherwise how could a MetaDataLoader that was a bean be integrated into the deployment MetaData view?

[adrian.brock]

The issue appears to be that for the plain deployment,
we don't necessarily have the classloader from which we can
create the annotations. e.g.

<deployment>
 <classloader><inject name="BeanConstructedLaterOrInThisFile"></classloader>
 <annotation>@from.that.Classloader</annotation>
</deployment>

It could create a static MetaDataLoader if the class loader was not a bean or a bean that was available, otherwise how could a MetaDataLoader that was a bean be integrated into the deployment MetaData view?

Yes that would be one possiblity. i.e. we create an artifical bean
that is responsible for populating the annotations in the DEPLOYMENT scope.

The other beans in the deployment would have to depend on it at the
PRE_INSTALL stage so they can see the correct annotations.

But that might create a circular dependency where the classloader for the
deployment is a bean within the deployment. Normally we allow you
to workaround the issue by adding

<classloader><null/></classloader>

(e.g. the VFS classloader stuff used in the bootstrap xml does this implicitly)
to that bean so we could possibly use the same to indicate that it shouldn't
wait for the deployment level annotations to get set up.