Lookup of beans of type fails for factory beans if type prediction is used. [SPR-10517]

[spring-projects-issues]

Oliver Drotbohm opened SPR-10517 and commented

Assume the following FactoryBean implementation:

class FactoryBeanImpl implements FactoryBean, MyInterface { … }

Beyond that, assume a BeanPostProcessor implementation that predicts the bean type of that FactoryBean to an arbitrary different type X. Now assume the following lookup code:

String[] names = beanFactory.getBeanNamesOfType(MyInterface.class);

This call returns an empty array if the bean instance for FactoryBeanImpl has not been created, but returns the name of the bean (as expected) once the instance has been created.

The reason for that behavior seems to start in DefaultListableBeanFactory.doGetBeanNamesForType(…), at the line where we try to find the match for the factory bean name. This code calls {{isTypeMatch(…). The first step it does is trying to lookup an already existing instance. In our second case (bean has already been created before) we run in this if clause and finally end up in the ClassUtils.isAssignableValue(typeToMatch, beanInstance) call, which results int true being returned.

If no instance has been created we run down until the call to predictBeanType(…). This call will set beanClass to the predicted type so that the type match is done against the predicted bean type although we're testing the factory dereference explicitly. IMO the code has to be changed to:

Class<?> beanClass = BeanFactoryUtils.isFactoryDereference(name) ? resolveBeanClass(mbd, beanName, FactoryBean.class) : predictBeanType(beanName, mbd, FactoryBean.class, typeToMatch);

---

Affects: 3.1.4, 3.2.2

Issue Links:

• DATAJPA-323 org.springframework.data.repository.support.Repositories doesn't find RepositoryFactoryInformation beans when using @EnableJpaRepositories ("is depended on by")
• BeanFactory does not return FactoryBeans by type when using type prediction and bean not yet created [SPR-9177] #13815 BeanFactory does not return FactoryBeans by type when using type prediction and bean not yet created
• BeanFactory does not return FactoryBeans in case the are looked up by type and type prediction is used [SPR-8954] #13594 BeanFactory does not return FactoryBeans in case the are looked up by type and type prediction is used

Referenced from: commits bc3e585, ef363b0

0 votes, 5 watchers

[spring-projects-issues]

Oliver Drotbohm commented

I've deployed a test case in Spring Data Commons (suffering from the issue). See spring-projects/spring-data-commons@cb3e701.

[spring-projects-issues]

Oliver Drotbohm commented

Actually the behavior feels like a regression of the fix for #13594, as it feels very close to the erroneous behavior originally reported in this ticket. Actually, reading further, it feels like the intended fix for #13815 doesn't really solve the issue as the test case posted above also fails with 3.2.2.

[spring-projects-issues]

Oliver Drotbohm commented

Thinking about it: can't isTypeMatch(…) be simplified to only do the type prediction and matching against the predicted type if the bean name is not a factory dereference?: E.g. for foo - do type prediction before matching, for &foo don't do type prediction and match the bean class only. It feels like the both scenarios are roughly covered by doGetBeanNamesForType(…) already, as it explicitly tries to match the type for the factory dereference if the attempt to match for the bean created by the factory didn't match in in the first place.

[spring-projects-issues]

Juergen Hoeller commented

Hey Ollie, since there's not much time left until 3.2.3: Please create an isolated test case for addition to Spring Framework's test suite, using a standalone dummy FactoryBean. That would be of great help to get this issue researched and fixed by Tuesday, and to avoid regressions going forward...

Juergen

[spring-projects-issues]

Oliver Drotbohm commented

I've opened a pull request with a test case currently annotated with @Ignored into the 3.2.x branch. The test cases available before did not reveal the erroneous behavior as they allowed implicit creation of the bean instance which leads to the detection of the beans eventually. The newly added test case explicitly prevents bean creation and fails.

[spring-projects-issues]

Juergen Hoeller commented

The whole problem originates in the semantics of SmartInstantationAwareBeanPostProcessor's predictBeanType method: As per its javadoc, the original purpose of that callback method is to predict the type returned by the same post-processor's postProcessBeforeInstantiation implementation. In other words, a predictBeanType impl usually goes with a custom postProcessBeforeInstantiation impl and is closely in sync with that method's behavior.

In Spring Data, you're not quite using it that way: You're predicting a FactoryBean-produced type instead, not doing anything in postProcessBeforeInstantiation. However, the core container simply always assumed that predictBeanType returns the instance type of the managed bean - so if that return value isn't a FactoryBean type, it assumed that postProcessBeforeInstantiation would replace the target FactoryBean with a non-FactoryBean.

That said, I have refined the algorithm to handle both scenarios on a best-effort basis now. The core container simply assumes that, when given a FactoryBean dereference ("&..."), the target has to be an actual FactoryBean - so if predictBeanType doesn't return a FactoryBean type, we're ignoring it since it probably just predicts the FactoryBean-produced type, and so we proceed with checking the original bean class for a FactoryBean type.

Juergen

[spring-projects-issues]

Oliver Drotbohm commented

Thanks, Jürgen. Confirmed fixed in the 4.0 and 3.2.3 snapshots.