DefaultListableBeanFactory.copyConfigurationFrom should provide independent AutowireCandidateResolver instance [SPR-14921]

[spring-projects-issues]

Marten Deinum opened SPR-14921 and commented

When using a GenericApplicationContextFactory it, by default, use the ConfigurableBeanFactory.copyConfigurationFrom method. This method also copies the AutowireCandidateResolver from the parent, which internally references a BeanFactory which effectively points to the parent instead of the current BeanFactory.

This introduces an issue when trying to resolve generic typed dependencies, which is an issue in the isAutowireCandidate in de DefaultListableBeanFactory which ultimately delegates to the configured AutowireCandidateResolver. This now tries to resolve/check the dependency with the parent instead of the current context.

To solve this for now we have a extended the GenericApplicationContextFactory and reset the AutowireCandidateResolver on the context created. This solves the issue of not being able to auto wire beans.

This could be a bug/issue in Spring itself instead of Spring Batch as the DefaultListableBeanFactory.copyConfigurationFrom is actually copying the autowireCandidateResolver.

---

Affects: 4.3.4

Issue Links:

• getBeanDefinitionNames should not leak the frozenBeanDefinitionNames array [SPR-14897] #19463 getBeanDefinitionNames should not leak the frozenBeanDefinitionNames array

Referenced from: commits ac5933a, 7ac9f92

[spring-projects-issues]

Michael Minella commented

I want to understand the last piece of this issue. Why does the DefaultListableBeanFactory#copyConfigurationFrom copy the autowireCandidateResolver if the candidates in the new BeanFactory may not be the same?

[spring-projects-issues]

Juergen Hoeller commented

Since AutowireCandidateResolver implementations are not necessarily BeanFactoryAware, that copying code simply wasn't specifically designed to deal with factory-specific state in those resolvers. Instead, for a factory-specific resolver, you had to manually override it afterwards. I've refined this for 4.3.5 now, providing an independent instance of the same type, configured for the target factory in case of BeanFactoryAware by default.

Additionally, we're also copying the dependency Comparator, the ConversionService and a custom TypeConverter now, finally catching up with all recent configuration state in the 4.x line.