[adrian.brock]

The main problem here being is that sometimes the aspect cannot specify or know its dependencies until it is bound into the thing it is aspectizing.

Exactly, but I don't see why this affects what we are talking about.

In the MC I have a stage called "DESCRIBE" this comes before
INSTANTIATE (contructor argument dependencies)
then CONFIGURE (attribute setter dependencies).

The idea of DESCRIBE is that it is not done until we know we have the class
available, here we can read the annotations.

Once we've read the annotations we can resolve which aspects will be required for the
container and add them to the metadata which will later affect the order in which
instantiation and configuration (including the aspects) are done.

[adrian.brock]

That not what I'm saying at all. I'm saying config COULD come from XML and that the common meta objects are instances of annotations rather than YET ANOTHER metamodel. Annotations in and of themsleves are meta objects.

This is not YET ANOTHER metamodel. This is THE metamodel, i.e. the one we
use natively. All other metamodels are "transformed" into it.

1) An annotation byself is meaningless.

e.g. the security domain annotation describes that I want a security domain
The metamodel of the MC also describes that, but additionally says exactly you
go about satisfying it.

2) As developers we don't want to deal with multiple sources of metadata.
It is the responsiblity of the deployers to turn their own domain specific metadata
into our single model.

3) By transformed I don't mean it necessarily has to do some xml transform or
create objects. It could just be a simple wrapper:

public Object getMetaData(...)
{
 return resolveAnnotation(...);
}

[bill.burke]

The idea of DESCRIBE is that it is not done until we know we have the class
available, here we can read the annotations.

Can you see why a getMetaData method needs to be on the joinpoint now? The pointcut expressions match on joinpoints, not invocations. We can't bind the aspects until we know the joinpoints of the class, bean, or container we're dealing with.


We don't know the dependencies until the aspect definitions have been bound. And finally, the aspect we're binding may be scope limited (PER_CLASS) meaing only one aspect per type should be created.

This can be implemented much easier, if the AspectFactory itself can query the bean, class, container for metadata and have a Kernel API that allows it to register dependencies or schedule additional aspect instantiations based on the scope of the aspec t(PER_CLASS, PER_INSTANCE, PER_JOINPOINT)

[adrian.brock]

You'll have to show me why it is easier.

Take the pathological case:

1) A bean is requested to be deployed that has the security annotation, BUT the
bean class is not deployed yet so we don't this yet.

2) When the bean class is deployed it then knows it needs to add the aspect and
metadata, but the aspect class is not deployed yet.
It does know enough to add the metadata to construct the aspect once the class is
available.

3) The aspect class is deployed we can look at it and see whether it has other
dependency injections.

etc...

Once all dependencies are satisfied it can then fully construct the aspect,
meaning it can construct the container which in turn means the bean is
now fully deployed.

[adrian.brock]

You can see earlier on in this thread I used joinPoint.getMetaData()
I have not been arguing against it.

I am arguing against having
getMetaData() and getAnnotation()
there should be one api (which might be neither or a combination of these)
unless there is good reason otherwise.

[bill.burke]

You'll have to show me why it is easier.

Take the pathological case:

1) A bean is requested to be deployed that has the security annotation, BUT the
bean class is not deployed yet so we don't this yet.

2) When the bean class is deployed it then knows it needs to add the aspect and
metadata, but the aspect class is not deployed yet.
It does know enough to add the metadata to construct the aspect once the class is
available.

It is the aspect that knows its dependencies. The aspect's factory doesn't know the security domain it depends on until it queries the bean's metadata. Furthermore, the aspect may need additional metadata from the bean class to determine its dependencies.

An even quirkier example is an aspect that is created PER_JOINPOINT and that aspect has a dependency based on metadata contained in the joinpoint, not the class.

I just don't see how you can define these types of dependencies in the current XML of the MC. Can you show me how? In fact, I don't think you can do it unless the MC has knowledge that an AOP framework is interacting with it. I don't think there is any other way than allowing the aspect factory to be able to register its dependencies itself.

3) The aspect class is deployed we can look at it and see whether it has other
dependency injections.

Yes, but the aspect class may not be able to specify it's dependencies in static metadata. It may have to have knowledge of its bean class before it can know its dependencies.

[adrian.brock]

Bill, we are going in circles.

You asked me to show you where this metadata is defined in the current xml
It is not, that is what we are discussing how to do here. That was my question earlier
in the thread.

You say the aspect needs to get metadata from the bean class/joinpoint.
I agree, that is the purpose of describe. Again annotations aren't implemented in
my prototype.

What I'm trying to understand is why we need two apis to get metadata
at runtime. I haven't since a convincing argument for this so I will assume
there isn't one.

Let's take a trivial example:
Somebody says they want to deploy a bean:

<bean name="..." bean="xxx"/>

They also want a container. There are two ways to do this.

1) They explicity wrap it in a container, either using xml or programatic definition
of the equivalent bean metadata (see examples earlier).
This is the long winded approach for people who want total control
of what is happening (5% of cases).

2) The SAME metadata comes from the "DESCRIBE" stage. i.e. when it loads
the class it discovers there are annotations and augments the metadata.
i.e. it adds the metadata and interceptors into the container definition.
Maybe it even adds a container to the definition if one wasn't present.
This is what most people will use (95% of cases).

Later, the aspect will use getMetaData() to retrieve this information.

There is also a hybrid approach where there maybe both tags on the class
and metadata already present in the bean metadata -
e.g. the "xml" override of annotations.

What I'm trying to get to is what changes do we need to plug in JBoss AOP
into the MC. My conclusions so far are:

1) We need to remove all notion of container from MC. We discussed this on
a different thread.
2) We need to add to the DESCRIBE stage of the MC to allow a hook
where a container can be plugged. It will register back additional bean metadata
like what aspects needs constructing, what metadata is present and whether
these have dependencies.
I see this more as a container factory since I want it to describe to MC
what needs constructing using Bean MetaData rather trying to create the container
objects.
annotations -> BeanMetaData
Letting the container factory create the container directly may not be possible
because other dependencies are not satisifed (classloading, jndi binding or
just plain IOC dependency).
3) The user has the option to use their own container metadata definition
(long winded metadata description) to get exactly what they want rather than
using the container factory. This is transparent to the MC since all it sees
is Bean MetaData to contruct the container objects in the correct order.
4) We need to consider a mixture of (2) and (3) where the user wants to
override what is coming from the class annotations, e.g. add an aspect, change
a metadata config, etc.

In (3) this may not even be an AOP container. But to take advantage of JBoss aspects
it needs to follow our container spi that defines the join points/invocation/etc.
Using the AOP container gives a lot more functionality than say a simple Proxy container.

[bill.burke]

I thought we were arguing over two things

1) That both joinpoint instances and invocation instances need metadata lookups. I think we both agree that joinpoint instances need metadata lookup. Do we agree that invocation intances need a separate metadata lookup?

2) I thought I had agreed that there doesn't need to be a separate API for getAnnotation and getMetaData. Maybe I agreed in my head, but forgot to post or maybe you didn't read one of my posts.

3) I thought we were disagreeing that the aspect factory needs a way to query for metadata from the bean class to determine additional dependencies. That I thought the aspect factory needed a way to query for metadata, and that you didn't.

Some thoughts:
* Class LEVEL: JBoss AOP Aspects are woven into a class at class static initialization time when using bytecode weaving (not a container + proxy). Will we be doing dependency management for this level of AOP? If so I'm worried about two things: complexity and performance. For complexity I'm worried that if we are doing dependency management at class static initialization we may run into difficult to debug deadlocks and circular class dependencies. For performance, I don't want to proxy aspect instances to solve complexity problems as the overall performance of JBoss AOP is quite sensitive as we're now down to the level of counting bytecode instructions.

* Bean Level: Do aspect dependencies at this level only worry about beans managed by aspectized containers?

* Finally, I think we need to discuss this on a separate thread, but I think the Joinpoints cannot use strings for parameters types, return types, and fields types. The AOP pointcut expression matcher will need to query these types to see if they have a corresponding annotation.

[adrian.brock]

Ok we agree on (1) and (2)
as long as the last part of (1)
means there will be a

JoinPoint.getMetaData() and
Invocation.getMetaData()

The JoinPoint.getMetaData() allows the lookup to be done at deployment time
but it does not require it. e.g. a perVM transaction demarcation aspect
may choose to do this at runtime via invocation.getMetaData() -> joinPoint.getMetaData();

[adrian.brock]

On (3) I'm not sure what this aspect factory is.

I do agree that some metadata/config will only be known when we resolve the
annotations from the class. Whether this is done by the aspect factory I don't know.

From the MC view point I was thinking of an integration point like:

public ContainerFactory
{
 BeanMetaData createContainer(BeanMetaData bmd)
}

that gets invoked at "describe" time in the lifecycle.

This says take the requested BeanMetaData and replace it with a bean
wrapped in a container + all its resolved metadata.

To ease the life of the ContainerFactory I was also thinking that there
would be a ContainerMetaData abstraction.
This would be a specialization of the BeanMetaData targeted at the common
container configurations so...
1) The ContainerFactory doesn't has a simpler task
2) The ContainerFactory can spot the user has already preconfigured
some parts of container. In this case the container factory will just augment
the preconfigured container.

[adrian.brock]

I don't want static class initialization for the containers from the MC.

This will work fine when beans are running inside somebody else's container
with the services from the wrapping container
but will fail for JBoss's internal beans where dependencies need to be
statisfied and ordered.

The ordering needs to be done by the MC - negating any deadlocks.

Pure JBossAOP
ClassNotFoundException x.Y
NestedException: NameNotFoundException: java:/jaas/SecurityDomain

With the MC it will wait for the jndi binding or you will get an error about
incomplete dependencies
DeploymentException: Unsatisfied dependency for 'Name'
NestedException: SecurityDomain not deployed

[adrian.brock]

Ok, lets move the join point/string problem to a separate thread.

[bill.burke]

On (3) I'm not sure what this aspect factory is.

Well, integrated with the MC the aspect factory would be responsible for registering its dependencies to the MC. IT would also be responsible for allocating instances of aspects based on their scope. (PER_VM, PER_CLASS, etc...)

I do agree that some metadata/config will only be known when we resolve the
annotations from the class. Whether this is done by the aspect factory I don't know.

From the MC view point I was thinking of an integration point like:

public ContainerFactory
{
 BeanMetaData createContainer(BeanMetaData bmd)
}

that gets invoked at "describe" time in the lifecycle.

This says take the requested BeanMetaData and replace it with a bean
wrapped in a container + all its resolved metadata.

Will BeanMetaData have an API to register dependencies? SO that the container or container factory can decide what dependencies it requires and so you can support all that stuff I talked about before where the aspect knows its dependencies, not the bean?

[bill.burke]

I don't want static class initialization for the containers from the MC.

This will work fine when beans are running inside somebody else's container
with the services from the wrapping container
but will fail for JBoss's internal beans where dependencies need to be
statisfied and ordered.

The ordering needs to be done by the MC - negating any deadlocks.

Pure JBossAOP
ClassNotFoundException x.Y
NestedException: NameNotFoundException: java:/jaas/SecurityDomain

With the MC it will wait for the jndi binding or you will get an error about
incomplete dependencies
DeploymentException: Unsatisfied dependency for 'Name'
NestedException: SecurityDomain not deployed

For static class initialization, I'm not talking about containers. I'm talkinag about when you are just weaving aspects into a class whose instances are created outside of the MC.

[adrian.brock]

Yes, BeanMetaData has a number of mechanisms for creating dependencies.

Off topic:
It is still on my todo list to come up with a generic mechanism for this
so the KernelController will spot any dependency in the metadata and generate
the necessary dependency list.

Currently it is a bit hardwired, e.g. it needs to know that

<attribute name="Blah"><depends ...></attribute>

adds a dependency to the KernelControllerState.CONFIGURED stage of the deployment.

See BasicKernelController.preprocessMetaData()