I have a question about BeanConfigurerSupport's destroy method.

The destory() method on BeanConfigurerSupport sets the beanFactory and beanWiringInfoResolver fields to null. This has the affect of leaving a BeanConfigurerSupport instance in a "less configured" state than when freshly instantiated since the beanWiringInfoResolver field is defaulted to a new instance of ClassNameBeanWiringInfoResolver. Further complicating things, AnnotationBeanConfigurerAspect sets calls setBeanWiringInfoResolver(new AnnotationBeanWiringInfoResolver()) in its constructor. Since aspects are singletons by definition, a call to AnnotationBeanConfigurerAspect.destroy() permanently clears the beanWiringInfoResolver.

This becomes a problem in the following scenario. Consider three integration test classes, all extending AbstractDependencyInjectionSpringContextTests. Test1 and Test3 both use appContextA.xml while Test2 uses appContextB.xml. Both appContextA.xml and appContextB.xml have <aop:spring-configured/> in them. The test classes run in the order Test1, Test2, and Test3.

For starters, each TestX class needs to call setDirty() to destroy the applicationContext created for the test class. Otherwise, when Test3 runs, the cached applicationContext is used and <aop:spring-configured/> is not reprocessed. This causes the AnnotationBeanConfigurerAspect to still reference the application context created from appContextB.xml. Calling setDirty() from onTearDown() works nicely but it calls AnnotationBeanConfigurerAspect.destroy() since the application context is destroyed. Now, when Test2's tests are run, the beanWiringInfoResolver is null.

I've worked around this issue by using the following bean definition instead of <aop:spring-configured/>:
Code:
<bean class="org.springframework.beans.factory.aspectj.AnnotationBeanConfigurerAspect" factory-method="aspectOf">
    <property name="beanWiringInfoResolver">
        <bean class="org.springframework.beans.factory.annotation.AnnotationBeanWiringInfoResolver"/>
    </property>
</bean>
Note that this is only a problem in unit/integration tests normally. Is this the expected behavior (especially given the complexity of this example) or should a JIRA issue be filed? I'd gladly provide a sample project that demonstrates the problem. Thanks for any guidance (and as always, thanks for the framework as a whole).