Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Oct 28, 2016 · 2 comments
Assignees
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Oct 28, 2016

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:

  • #19463 getBeanDefinitionNames should not leak the frozenBeanDefinitionNames array

Referenced from: commits ac5933a, 7ac9f92

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 18, 2016

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 21, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.