AspectJ aspectOf - problem

[bpolka]

I have an AspectJ aspect that needs to be injected with a spring managed component. I tried to use factory-method="aspectOf" on my class for the aspect and it works nicely on aspects that are not decared as perthis, pertarget or percflow.

The question is: what do I do with those that are declared as perthis, pertarget or percflow?

[Rod Johnson]

The question is: what do I do with those that are declared as perthis, pertarget or percflow?

As singleton aspects are the commonest, I prioritized support for them in 1.1 implementation, samples and examples, although I added a little functionality in the core container that should facilitate handling other aspect types.

I'm still thinking about the approach for other aspect bindings. As it happens, I'm seeing Adrian Colyer (AspectJ lead) today, so I'll have another chat to him about it and let you know if we come up for anything...

[adrian_colyer@uk.ibm.com]

Sorry it's taken me a few days to get here and get registered etc...

The perXXX aspects raise some interesting questions. Rod won't like me for saying this ( :wink: ), but Spring basically creates a singleton for each named bean in the configuration file. Also by default, these instances are created up-front. These exact properties are what enable regular (singleton) aspects to fit so well into the framework. For perXXX aspects there are two issues: the first is how to map aspect instances onto named beans, and the second is how Spring can obtain the aspect instance to configure once.

The mapping issue is easy to understand. Take a perthis aspect - you could have say 5 instances of this aspect in a running program at some point in time. Do *all* of these instances map onto the same bean for configuration purposes? Initially at least it simplifies things if that is the case (do you have a use-case where this strategy would be inadequate?). If they do all map onto the same bean, how do we know which bean that is? Defining a bean with the same name as the aspect is one easy strategy, though it could be fragile and is not quite in the Spring 'spirit'.

Spring likes to create the beans it configures (though the factoryMethod support does allow for strategies that return existing instances - this is exploited by the "aspectOf" trick for singleton aspects). With perXXX aspects these need to be created by AspectJ, and at a point in the runtime execution of the program determined by AspectJ (whereas singleton aspects can be created up front). The best solution seems to be that aspects "pull" their configuration from Spring after they have been created. This requires the ability in Spring to ask for a pre-exisiting instance to be configured. I haven't had a chance to look at this yet, but the intriguing entry in the Spring 1.1 release notes

* added "applyBeanPropertyValues" method to AutowireCapableBeanFactory, for populating an existing bean instance

might allow us to do just that. The actual pull itself is a cross-cutting concern and could be coded as another aspect (that ultimately should make its way into a library). Something like:

aspect SpringAspectConfiguration {

// not the right type, just to give the idea...
// set by dependency injection from Spring itself
public void setSpringContainer(SpringContainer container) {...}

public interface SpringConfigured {} // marker

after(SpringConfigured newInstance) returning :
execution(SpringConfigured+.new(..)) && this(newInstance) {
String beanName = newInstance.getClass().getName();
container.configure(beanName,newInstance); // pseudo-code!
}

}

and then in an aspect particular to your configuration:

aspect MySpringAspectConfiguration {

// A, B & C are the perxxx aspects you want Spring to configure
// post-creation
declare parents : (A || B || C) implements SpringAspectConfiguration.SpringConfigured;
}

You can probably tell i haven't tried this yet, just thinking as I type .

I'm also interested in extending AspectJ to support multi-instance aspects (user instantiated). This would enable multiple beans to be created with the same aspect type, and Spring could then create an instance of each. If you have use cases where this would be useful to you, I'd really like to hear them too.

[Rod Johnson]

Adrian

Good to see you posting here!

This requires the ability in Spring to ask for a pre-exisiting instance to be configured

AutowireCapableBeanFactory includes a range of methods for configuring existing objects.

You can get an AutowireCapableBeanFactory from the ConfigurableApplicationContext.getBeanFactory() method. The Spring ApplicationContext implementations all implement ConfigurableApplicationContext.

Rgds
Rod