using the registry/ClassAdapter.getDependencies()

[bill.burke]

I'm currently going to iterate and try to implement all the aspect factories and see if I can get a woven class to publish its aspect dependencies to the kernel. There's a few things I need to know:

* When I need to create an aspect, how do I resolve it. Will it be in the registry if the dependencies have been resolved yet? If it will exist in registry when dependencies are NOT resolved, how do I determine if dependencies have been resolved or not?

* ClassAdapter.getDependencies() is currently not called anywhere. I need to know where this method should go, or you need to add the integration of this to the kernel yourself.

THanks,

[adrian.brock]

I'm currently going to iterate and try to implement all the aspect factories and see if I can get a woven class to publish its aspect dependencies to the kernel. There's a few things I need to know:

* When I need to create an aspect, how do I resolve it. Will it be in the registry if the dependencies have been resolved yet? If it will exist in registry when dependencies are NOT resolved, how do I determine if dependencies have been resolved or not?

It won't be in the registry if dependencies aren't resolved.
It will be known to the controller regardless

 KernelRegistryEntry getInstalledContext(Object name);

* ClassAdapter.getDependencies() is currently not called anywhere. I need to know where this method should go, or you need to add the integration of this to the kernel yourself.

THanks,

No, I didn't know how you were going to do this, or the ClassAdapter for
that matter.
It belongs in AbstractKernelController$AbstractDescribeAction
and needs to update the context's dependency info:

 BeanMetaData metaData = context.getBeanMetaData();
 BeanInfo info = configurator.getBeanInfo(metaData);
 context.setBeanInfo(info);
 // HERE

I currently hide the ClassAdapter inside the BeanInfo abstraction.

If you can tell me what the api is I have no problem about doing it.
It is little more than

DepedencyInfo depends = context.getDependencyInfo();
for (Object o : beanInfo.getDepedencies()) // ClassAdapter.getDependencies or whatever
 depends.addIDependOn(new AbstractDependencyItem(KernelControllerState.INSTANTIATE, o, metaData.getName(), KernelControllerState.INSTALLED));

[bill.burke]

*on lookup question*

So, I get access to the Kernel and then first lookup in the registry to see if Aspect is there. If it is not there, I look in the KernelController to see if it is currently in deployment mode. If it *does not* exist within the KernelController I throw an exception UNKNOWN_ASPECT if does exist in the KernelController I thrown an exception ASPECT_NOT_DEPLOYED or whatever...

I can figure out from the testsuite how to get a reference to the Kernel? The Kernel should be the entry point into the entire system?

*on ClassAdapter*

I thought ClassAdapter.getDependencies would return a list of Strings? The List of Strings I can easily populate. Is this what you need for API clarification?

ClassAdapter.getDependencies needs to happen before the bean is instantiated. So, the dependencies need to be added and resolved before the bean is instantiated. Is this possible?

* I guess I also need to know how to plug in a ClassAdapterFactory. I don't see any hooks anywhere for this. I guess this would be a change in the AbstractKernelConfig and Kernel itself? If you want me to do this, I can probably figure it out.

Bill

What more exactly do you need from me?

[adrian.brock]

*on lookup question*

So, I get access to the Kernel and then first lookup in the registry to see if Aspect is there. If it is not there, I look in the KernelController to see if it is currently in deployment mode. If it *does not* exist within the KernelController I throw an exception UNKNOWN_ASPECT if does exist in the KernelController I thrown an exception ASPECT_NOT_DEPLOYED or whatever...

I can figure out from the testsuite how to get a reference to the Kernel? The Kernel should be the entry point into the entire system?

You don't *get* anything it is pushed to you (IOC)
We want the AspectManager to be deployed as a mc javabean (instead of an
mbean - no changes required here).

Then the jboss-aop.xml would be deployed either through the aspectized
deployer or by direction installation of your metadata model.

Currently you don't have a metadata model, but what we want to do is the
equivalent of
xml -> MC instantiation of AspectMetaData (using Alex's JBossXB)
or somebody could construct it programmatically.

This metadata deployment would then be installed on the controller
including the dependency injection of the AspectManager and at
AspectMetaData.create() it would install the metadata.

This allows us to take parts of the AspectMetaData
(like the aspect factories) and add injections to those
e.g. the tx advice needs to be injected with the transaction manager,
it can declare this in its bean description.

[adrian.brock]

You don't *get* anything it is pushed to you (IOC)

The alternative is to make the aspect factories into a KernelRegistryFactory
such that the dependency mechanism uses the AspectManager like JNDI
but then you lose the ability to inject into the aspect configuration.
I don't see your aspect configuration, only which aspects are registered.

[adrian.brock]

* When I need to create an aspect, how do I resolve it. Will it be in the registry if the dependencies have been resolved yet? If it will exist in registry when dependencies are NOT resolved, how do I determine if dependencies have been resolved or not?

That is the microcontainer's job. i.e. don't instantiate services until the
dependencies (including advice dependencies) are satisfied.

[bill.burke]

No, no, and no...

This is not how we agreed how it would work and I really don't feel like walking through this again as we spent at least a day arguing through this stuff.

The ClassAdvisor controls when aspects are created, not the IoC container. AspectFactories have additional metadata (scope) on when and how many times they are created. Also, AOP has additional injected types that cannot be resolved through the IoC container and must be resolved by AOP when AOP decides to instantiate.

So, IoC container will inject dependecies into the aspect via the GenericBeanFactory. The AOP ClassAdvisor needs to be able to lookup these GenericBeanFactories so it can decide when the Aspect is created.

Also, aspect factories sometimes have no idea how to resolve dependencies until they are bound to the class they are weaving into. i.e SecurityDomain. Don't you remember going through this exercise?

Anyways, please just answer my questions so that I can continue working...

Bill

[adrian.brock]

* ClassAdapter.getDependencies() is currently not called anywhere. I need to know where this method should go, or you need to add the integration of this to the kernel yourself.

I answered that in the other thread.

[bill.burke]

Also, JBoss AOP *has* a metamodel. The only metamodel it doesn't have is Aspect configuration stuff (the IoC metadata).

[bill.burke]

Another thing, the way it would work would be that the AspectDeployer would deploy GenericBeanFactories into the IoC Container programmatically. I need to be able to inherit from GenericBeanFactory to provide my own additonal metadata that the AspectFactory needs. (Scope).

So, I still need answers to:

1) How to plug in a ClassAdapterFactory. I may be able to figure this out myself, not positive.
2) I think I can figure out from your first response where to integrate ClassAdapter.getDependencies(), not positive.

Bill

[adrian.brock]

No, no, and no...

This is not how we agreed how it would work and I really don't feel like walking through this again as we spent at least a day arguing through this stuff.

And we are talking about different things again.

The ClassAdvisor controls when aspects are created,
not the IoC container.

Correct

AspectFactories have additional metadata (scope) on when and how many times they are created. Also, AOP has additional injected types that cannot be resolved through the IoC container and must be resolved by AOP when AOP decides to instantiate.

The aspect factories require configuration/injection this is done by the MC.
The aop framework is then responsible for doing factory.create() to create
the advices.

So, IoC container will inject dependecies into the aspect via the GenericBeanFactory. The AOP ClassAdvisor needs to be able to lookup these GenericBeanFactories so it can decide when the Aspect is created.

These are injected into the AspectMetaData/AspectFactory/GenericBeanFactory,
not the aspect.
Currently this is not possible because jboss-aop.xml reads the xml and does the construction directly from it.

Also, aspect factories sometimes have no idea how to resolve dependencies until they are bound to the class they are weaving into. i.e SecurityDomain. Don't you remember going through this exercise?

Yes that is the @Dependency annotation:

@Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME)
@Dependency(name="value") // HERE value() represents something to depend upon
public @interface SecurityDomain
{
 String value();
}

[adrian.brock]

1) How to plug in a ClassAdapterFactory. I may be able to figure this out myself, not positive.

The bootstrap constructs a KernelConfig.

The KernelConfig has a getBeanInfo() which is what decides the ClassAdaptor
to use.

It is simply a case of replacing the AbstractKernelConfig with an implementation
that does more than ask for a Reflection based classadapter.

[adrian.brock]

e.g. the tx advice needs to be injected with the transaction manager,
it can declare this in its bean description.

This looks to have caused the confusion, I will reword it more precisely.

The GenericBeanFactory used by the AspectFactory for the tx advice
needs a TransactionManager injection.

[bill.burke]

So, IoC container will inject dependecies into the aspect via the GenericBeanFactory. The AOP ClassAdvisor needs to be able to lookup these GenericBeanFactories so it can decide when the Aspect is created.

These are injected into the AspectMetaData/AspectFactory/GenericBeanFactory,
not the aspect.
Currently this is not possible because jboss-aop.xml reads the xml and does the construction directly from it.

This does not happen at deployment. The XML fragment in the aspect declaration in jboss-aop.xml is stored for later use when then aspect is actually created/instantiated. It is just a matter of writing a new AspectFactory implementation and plugging it in.

Also, aspect factories sometimes have no idea how to resolve dependencies until they are bound to the class they are weaving into. i.e SecurityDomain. Don't you remember going through this exercise?

Yes that is the @Dependency annotation:

@Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME)
@Dependency(name="value") // HERE value() represents something to depend upon
public @interface SecurityDomain
{
 String value();
}

This @Dependency annotation only tells the MC about the dependency. The MC doesn't know how/where this dependency should be injected. The @SecurityDomain is on the bean class and it is the aspect that needs this information to lookup and set the dependency within the aspect. A distinct, non-GenericBeanFactory implementation of an AspectFactory would be needed here. It would work the same way the Security aspect works now in the current impl except that they MC would be able to hold up bean creation because the SecurityDomain dependency would be published to it via the @Dependency annotation.

[adrian.brock]

Just to round off the discussion and what I think we agreed.

1) The MC will inject dependencies into GenericBeanFactories
where advices need injections. These GBFs will be used by a generic
aspect factory to construct the advices as required according to scope.

2) The MC needs to know about the @Dependency annotations of the
class and the relevent AspectFactories names so it can correctly workout the
dependency order as it starts services.

3) There will be an aspect deployer that does
xml -> MC config to construct and install Aspect metadata
instead of the AspectXMLLoader/Deployer
The advice dependcies can be defined through
a) annotations on the advice class using (2) above
b) annotation overrides in the MC config
c) plain MC depends xml config