Issue 1:
Ramnivas Laddad opened SPR-4306 and commented

Currently, the base aspect for domain object dependency injection -- AbstractBeanConfigurerAspect -- is not really capable of doing many interesting things that its subaspect AnnotationBeanConfigurerAspect does. Especially important capability is injecting dependencies after deserialization. This precludes users from creating useful subaspect of AbstractBeanConfigurerAspect unless they duplicate the functionality in AnnotationBeanConfigurerAspect. This, in turn, precludes some interesting possibilities such as:

Injecting dependencies based on user-specific annotations.

Injecting based on user-specified interfaces (e.g. Injecting MailServer for objects implementing MailClient).

User specified configuration strategy (that can bypass Spring's reflection based strategy).

While making backwards compatible changes is ideal in some respect, it is probably going to end up making the design too complex (already we have some complexities such as non-abstract pointcut that must be overriden). So perhaps a better choice is to:

Create a new aspect, say, AbstractDependencyInjectionAspect with consideration for all things mentioned above.

Deprecate AbstractBeanConfigurerAspect.

This shouldn't be a real issue for any existing users as their subaspects of AbstractDependencyInjectionAspect, if any, will continue to work the same way.

Refactor AnnotationBeanConfigurerAspect to extend AbstractDependencyInjectionAspect.

Since AnnotationBeanConfigurerAspect is a concrete aspect (which cannot be extended further), there is no issue with user extensions to it. Further, most (all?) Spring users use this aspect to aop:spring-configured/ or context:spring-configured/ anyway, making internal details umimportant to them.

Issue Links:

#8980 Deserialization not reinjecting for @Configurable with preConstruction

#8981 Repeated configuration for @Configurable with preConstruction

Issue 2:
Marc Ludwig opened SPR-6121 and commented

Overview

We have a large number of unit/integration tests that assert behavior within our system and rely upon injection of dependencies into configurable domain objects.

These tests all work when executed individually; however, when executed within a suite (either through the IDE or Ant) certain tests fail as dependencies have not been injected into the @Configurable objects. We have also seen dependencies that were configured for test X being injected into test Y rather than the dependencies for test Y; but I have no test case for this.

Steps to Reproduce

I have created a set of three tests -- tests 1 and 3 are basically identical. If these are executed in a suite the third test will fail as the dependency is not injected into the @Configurable object even though it is available to the test. This only occurs if test 2 is a Spring test.

See attached zip file.

Further Resources

Spring Test Context Caching + AspectJ @Transactional + Ehcache pain blog by Java Code Geeks

Affects: 2.5.6, 3.0.5

Reference URL: http://forum.springsource.org/showthread.php?t=77980

Attachments:

springtest.zip (3.15 MB)

Issue Links:

#15989 SpringContexts not properly closed after test-class is finished ("is duplicated by")

#11019 TestContext framework should support one AspectJ instance per ApplicationContext

#17123 AnnotationTransactionAspect retains reference to JpaTransactionManager from closed context

11 votes, 14 watchers