Annotation features

[alesj]

Since there is a really increasing demand for annotation usage with MC configuration, I think we should _finally_ provide a generic MC beans annotations handling.

There are already some annotations present, but I think their lookup is scattered all over the place.

I also went through some old posts which just touch on the topic of annotations:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=89400
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=88620&postdays=0&postorder=asc&start=0
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=88613&postdays=0&postorder=asc&start=0

There are some pointers to use the ClassInfo/BeanInfo:

The inspection should come from "reflection abstraction"
in the container module which is integrated via the
Configurator/BeanInfo.

But is looks like this is not yet fully implemented:

Which AFAIK, (Kabir may know better) isn't properly integrated
except when AOP is used. i.e. The Bean/ClassInfo is not updated
with the annotation overrides.

Regarding the scattering:

1) I've started with a simple annotation handling with AnnotationDependencyBuilder and DependencyFactory(Lookup), but this is not yet enabled - DependencyBuilder is not pluged in.
There was a question about using a chain of DependencyBuilders, but that's where it stopped.
- http://www.jboss.com/index.html?module=bb&op=viewtopic&t=107268

2) But on the other hand I'm doing a whole annotation lookup through MetaDataRepository in PreInstallAction.

3) And I do a straight annotation lookup via BeanInfo in LifecycleAction.

I like the AnnotationDependencyBuilder with DependencyFactory approach - ok, some weak caching is missing and some other features - but if we are able to provide a generic annotation handling that way ...

I guess some of the actual annotation handling will/is depending on the ControllerState we are in - specially regarding classes being present and actual bean instantiation with beanfactory.
Perhaps doing DependencyBuilders depending on the state?

Is changing the BeanMetaData legal when handling annotations?
Or we need to do the cloning before this?

[adrian.brock]

"alesj" wrote:

There are some pointers to use the ClassInfo/BeanInfo:

The inspection should come from "reflection abstraction"
in the container module which is integrated via the
Configurator/BeanInfo.

But is looks like this is not yet fully implemented:

Which AFAIK, (Kabir may know better) isn't properly integrated
except when AOP is used. i.e. The Bean/ClassInfo is not updated
with the annotation overrides.

The plan to update the Bean/ClassInfo was dropped (or at least shelved)
since it was too much work for AOP.

Instead, you should use the MetaData from the MetaDataRepository for that instance.
That is where the overridden annotations are stored at the instance level.

Regarding the scattering:

1) I've started with a simple annotation handling with AnnotationDependencyBuilder and DependencyFactory(Lookup), but this is not yet enabled - DependencyBuilder is not pluged in.
There was a question about using a chain of DependencyBuilders, but that's where it stopped.
- http://www.jboss.com/index.html?module=bb&op=viewtopic&t=107268

2) But on the other hand I'm doing a whole annotation lookup through MetaDataRepository in PreInstallAction.

3) And I do a straight annotation lookup via BeanInfo in LifecycleAction.

I like the AnnotationDependencyBuilder with DependencyFactory approach - ok, some weak caching is missing and some other features - but if we are able to provide a generic annotation handling that way ...

I guess some of the actual annotation handling will/is depending on the ControllerState we are in - specially regarding classes being present and actual bean instantiation with beanfactory.
Perhaps doing DependencyBuilders depending on the state?

Is changing the BeanMetaData legal when handling annotations?
Or we need to do the cloning before this?

Don't follow the rest of this, I still haven't had to look at what you and Kabir did
in this area.

IMHO, the BeanMetaData should always be cloned, even if it just avoids

BeanMetaData bmd = ...
controller.registerContext(bmd);
bmd.changeIt() // oops - which version of bmd gets used?

[alesj]

Instead, you should use the MetaData from the MetaDataRepository for that instance.
That is where the overridden annotations are stored at the instance level.

Yup, learned that one from PreInstall scoping lookup.

Don't follow the rest of this, I still haven't had to look at what you and Kabir did in this area.

Any pointers then to follow?
So that I don't go astray as in name-aware ... :-(

[adrian.brock]

"alesj" wrote:

Don't follow the rest of this, I still haven't had to look at what you and Kabir did in this area.

Any pointers then to follow?
So that I don't go astray as in name-aware ... :-(

Discuss it with Kabir. He's your partner in crime in this area. :-)

Like I said before, I'll eventually get around to reviewing
it all and telling you what is wrong with it. :-)

In principle it should just be about populating the BeanMetaData from the annotations
where there it doesn't already exist - i.e. what the user provides overrides
(either xml or programmatic overrides the annotations).

The difficult part I can see comes from the factory processing where you don't know
the implementation class until the factory has instantiated the object.

[alesj]

Instead, you should use the MetaData from the MetaDataRepository for that instance.
That is where the overridden annotations are stored at the instance level.

BasicKernelMetaDataRepository.java

 /**
 * Initialise metadata retrieval
 *
 * TODO lots more work
 * @param context the context
 * @return the retrieval
 */
 protected MetaDataRetrieval initMetaDataRetrieval(KernelControllerContext context)
 {
 MutableMetaDataRepository repository = getMetaDataRepository();
 ScopeKey scopeKey = context.getScope();
 ArrayList<MetaDataRetrieval> retrievals = new ArrayList<MetaDataRetrieval>();
 for (Scope scope : scopeKey.getScopes())

This is probably where this should already be stored/done, but the TODO is not that overwhelming ... :-)

I'm trying to do this:

 // properties
 Set<PropertyInfo> properties = info.getProperties();
 if (properties != null && properties.isEmpty() == false)
 {
 for(PropertyInfo pi : properties)
 {
 Signature pis = new MethodSignature(pi.getName(), Configurator.getParameterTypes(trace, new TypeInfo[]{pi.getType()}));
 MetaDataRetrieval cmdr = retrieval.getComponentMetaDataRetrieval(pis);
 if (cmdr != null)
 {
 System.out.println("cmdr = " + cmdr);
 }
 }
 }

Or what's the way to 'join' info from MetaDataRetrieval and [Class|Property|Method]Info, and populate BeanMetaData.

[alesj]

"alesj" wrote:

Or what's the way to 'join' info from MetaDataRetrieval and [Class|Property|Method]Info, and populate BeanMetaData.

This is already working. ;-)
The thing was that PropertyInfo is first split into getter and setter and than added as a component metadata retrieval.

[alesj]

How to trigger all those checks from MetaDataVisitorNode.[initial|describe]Visit?

e.g. when I run into @Inject annotation, I add an AbstractInjectionValueMetaData to BeanMetaData (if that property is not already defined ...), but I'm missing all those checks previously done - from setting the context ref, adding dependencies, ...

[alesj]

"alesj" wrote:
How to trigger all those checks from MetaDataVisitorNode.[initial|describe]Visit?

Solved by new wrapper around MetaDataVisitor. ;-)
We'll see if the final solution is OK. :-)