Dependency Injection issue when using ManagedMap or ManagedList in BeanDefinitionParser [SPR-11131]

[spring-projects-issues]

Chris Mathews opened SPR-11131 and commented

I just hit an issue when upgrading one of my projects from Spring 3.2.4 to 3.2.5. Here is the basic scenario simplified down to the core details:

• Implemented a custom Spring namespace
• Programatically wiring up a bean class, let's call it WidgetRegistry that maintains a Map<String, WidgetStack>
• The WidgetStack instances are also programatically wired in the namespace and they maintain a List<Widget>.
• The Widget is a simple class that has one member variable injected on it using @Inject.

I have tested this scenario from 3.0.0 all the way up to 3.2.4 and everything works as expected (4.0.0.M1 - M3 also work). When I upgrade to 3.2.5, 4.0.0.RC1 or 4.0.0-SNAPSHOT however things explode. The problem is that the Widget instances (inside the List) are no longer being injected upon. To be more exact only the first element (index 0) is not being injected upon... the rest of the Widget instances are being fully populated. This also only occurs when implemented as part of a custom namespace using ManagedMap and ManagedList to wire the appropriate Collections. If I wire the beans explicitly in Spring xml then everything works as expected.

Attached is a small sample project I threw together to demonstrate the problem.

---

Affects: 3.2.5, 4.0 RC1

Attachments:

• spring-test.zip (10.52 kB)

Issue Links:

• Providing unique names to prototype inner beans causes excessive memory and CPU use [SPR-11545] #16170 Providing unique names to prototype inner beans causes excessive memory and CPU use

Referenced from: commits 242ecdc, d0fc38e

Backported to: 3.2.6

[spring-projects-issues]

Juergen Hoeller commented

This turned out to be a side effect of our change towards bean-specific caching in AutowiredAnnotationBeanPostProcessor and co, instead of the previous class-based caching. There was one scenario that we missed: Inner beans with multi-level nesting like in your case, which led to the reuse of the same inner bean name and hence to an misplaced cache hit... A problem that we always had but never discovered before relying on those bean names for caching.

Anyway, fixed for 4.0 GA and 3.2.6 now. Thanks for the timely report!

Juergen

[spring-projects-issues]

Chris Mathews commented

I tested my internal project against both 3.2.6.BUILD-SNAPSHOT and 4.0.0.BUILD-SNAPSHOT and everything works as expected now. Thanks Juergen!