Type resolution fails for uninitialized factory-method declaration [SPR-11112]

[spring-projects-issues]

Rod Widdowson opened SPR-11112 and commented

Attached are a simple program and xml file to demonstrate.

1. two beans are defined
2. They are searched for by Class and then by Name and then by Class again.
3. Only one of the two initial searches by class succeeds.
4. Both the search by name succeed.
5. Both the second search by Class succeed.

I'm no expert so pilot error could be implicated.

This worked in 3.2.2.RELEASE but does not in 3.2.5.RELEASE

Thanks

---

Affects: 3.2.5

Attachments:

• ccc.xml (873 bytes)
• SpringBug.java (2.10 kB)

Referenced from: commits 8e52e65, 5dcd287

Backported to: 3.2.6

1 votes, 5 watchers

[spring-projects-issues]

Juergen Hoeller commented

I can confirm that this is an issue with your concrete test scenario. Note, however, that you should call "refresh()" on your ApplicationContext before accessing any beans; in Spring 4.0, we're even enforcing that. With such a fully initialized ApplicationContext, the problem goes away.

That said, I'm still researching the underlying cause. I'm going to sort it out for the non-initialized case as well, just to be sure we're not missing anything in our algorithm.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Guava's CacheBuilder has two "build" methods with different return types declared (Cache vs LoadingCache), which is why our type resolution algorithm considers them ambiguous. Once initialized, we have called a specific factory method in the present context, so we have a clearly resolved type.

I've refined the pre-initialization algorithm to determine a common ancestor as well (i.e. Cache for Cache vs LoadingCache), so your scenario works without a "refresh()" call as well now. That said, you should nevertheless always call "refresh()" once you're done with your configuration steps - not least of it all since Spring 4.0 insists on such a call.

Juergen

[spring-projects-issues]

Rod Widdowson commented

Thanks for the speedy analysis. I knew there had to be PEBKAC somewhere..

/Rod