[aloubyansky]

Unless Adrian wants to look into that, I can.

[wolfc]

The problem for EJB 3 is meta data translation and meta data repository.

For example defining a stateful bean with a remove method:

<enterprise-beans>
 <session>
 <description>A stateful bean</description>
 <ejb-name>StatefulBean</ejb-name>
 <local>org.jboss.ejb3.test.stateful.Stateful</local>
 <ejb-class>org.jboss.ejb3.test.stateful.StatefulBean</ejb-class>
 <remove-method>
 <bean-method>
 <method-name>removeBean</method-name>
 </bean-method>
 </remove-method>
 </session>
 </enterprise-beans>

is the same as:

package org.jboss.ejb3.test.stateful;

@Stateful(description="A stateful bean")
@Local(Stateful.class)
public class StatefulBean implements Stateful
{
...
 @Remove
 public void remove() { }
}

or:

package org.jboss.ejb3.test.stateful;

@Stateful(description="A stateful bean")
public class StatefulBean implements Stateful
{
...
 public void remove() { }
}

@Local
public interface Stateful
{
 @Remove
 void remove();
}

You can see that a Description annotation never even enters the picture.

Secondly we use the class container as meta data repository, so we can do this:

<bind pointcut="execution(public * *->@javax.ejb.Remove(..))">
 <interceptor-ref name="org.jboss.ejb3.stateful.StatefulRemoveFactory"/>
 </bind>

Again the public API annotations are leading.

Another problem: we can't use the API annotations to express all meta data, because they're not conclusive. Not everything can be expressed in annotations. So I would rather have the unified meta data as the base, which is conclusive and un-ambiguous and some translator on top. So if you ask for getAnnotation(@Remove) it will look it up in the right meta data repository in the right meta data.

[anil.saldhana]

"wolfc" wrote:

Another problem: we can't use the API annotations to express all meta data, because they're not conclusive. Not everything can be expressed in annotations. So I would rather have the unified meta data as the base, which is conclusive and un-ambiguous and some translator on top. So if you ask for getAnnotation(@Remove) it will look it up in the right meta data repository in the right meta data.

I support the idea of the meta data repository being the source of all questions for an annotation. So a question on container.resolveAnnotation should go to the metadata repository.

[starksm64]

"wolfc" wrote:

You can see that a Description annotation never even enters the picture.

Right. What is needed is an annotation scanning deployer that has a plugin maps a set of annotations onto the metadata instance that resulted from the parse phase. If its a pure annotation deployment it would create the metadata from the annotations. The steps should be:
1. annotation scanning deployer provides sets of annotations based on the types the plugins have defined. This is used to create the base metadata.
2. Parsing deployer would create the next level of metadata that delegates to the annotation based instance.

"wolfc" wrote:

Secondly we use the class container as meta data repository, so we can do this:

<bind pointcut="execution(public * *->@javax.ejb.Remove(..))">
 <interceptor-ref name="org.jboss.ejb3.stateful.StatefulRemoveFactory"/>
 </bind>

This should be metadata on the managed aspect mc bean. We talked with Kabir about this today. The stateful ejb3 container should have a number of beans for the aspects associated with a stateful container domain.

"wolfc" wrote:

Another problem: we can't use the API annotations to express all meta data, because they're not conclusive. Not everything can be expressed in annotations. So I would rather have the unified meta data as the base, which is conclusive and un-ambiguous and some translator on top. So if you ask for getAnnotation(@Remove) it will look it up in the right meta data repository in the right meta data.

I would say there should never be a lookup for an annotation, unless that is the proper metadata. The annotation should have been translated into the metadata by the annotation scanning deployer/annotation to metadata plugin.

[wolfc]

Right. What is needed is an annotation scanning deployer that has a plugin maps a set of annotations onto the metadata instance that resulted from the parse phase. If its a pure annotation deployment it would create the metadata from the annotations. The steps should be:
1. annotation scanning deployer provides sets of annotations based on the types the plugins have defined. This is used to create the base metadata.
2. Parsing deployer would create the next level of metadata that delegates to the annotation based instance.

Okay, I'm working on a component that does the creation of metadata from annotations. We can hook that to a deployer.