ObjectFactory lacks method for getting bean with specified constructor arguments [SPR-13956]

[spring-projects-issues]

Frank Scheffler opened SPR-13956 and commented

While BeanFactory supports retrieving prototyped beans with additional constructor or factory-method arguments (#15860), the org.springframework.beans.factory.ObjectFactory is still missing such method.

ObjectFactory is often used in test fixtures, where lookup-method injection et.al. cannot be used, in order to get access to prototype bean instance. Using the BeanFactory directly in such cases is currently the only way to solve this.

---

Affects: 4.2.4

Issue Links:

• Regression: SPR-12443 breaks singleton bean references within a configuration class with null arguments [SPR-13887] #18460 Regression: SPR-12443 breaks singleton bean references within a configuration class with null arguments
• An ObjectFactory variant with lenient not-unique handling [SPR-13943] #18515 An ObjectFactory variant with lenient not-unique handling
• BeanFactory lacks method for getting bean by type with specified constructor arguments [SPR-11235] #15860 BeanFactory lacks method for getting bean by type with specified constructor arguments
• Mis-proxying of Mockito mock and poor diagnostics for type mismatch on proxy injection [SPR-14478] #19047 Mis-proxying of Mockito mock and poor diagnostics for type mismatch on proxy injection
• Support dynamic bean lookup a la CDI's Instance type [SPR-13132] #17723 Support dynamic bean lookup a la CDI's Instance type

Referenced from: commits ed98393, 890819f

[spring-projects-issues]

Juergen Hoeller commented

This looks like a straightforward addition to 4.3's new SmartObjectFactory, as introduced in #18515...

[spring-projects-issues]

Frank Scheffler commented

I am not sure SmartObjectFactory is the right place, since it is not about whether the bean is available or not. Actually, I was thinking about the equivalent of BeanFactory.getObject(Class<T>, Object... parameters), simply without providing the type, since ObjectFactory already knows the type.

One could even go as far as adding the var-args parameters to the existing getObject()-method, however the JavaDoc may become a little confusing in that case.

[spring-projects-issues]

Juergen Hoeller commented

Well, SmartObjectFactory is not strictly about optional availability. It is a way to introduce new methods withour breaking custom implementors of ObjectFactory itself: That interface serves for several purposes, not just as an injection point handle, and we can't easily add methods to it or change the existing getObject() signature in a non-binary-compatible way there.

From another perspective, conceptually, ObjectFactory is just a plain retrieval mechanism which implies no bean container concepts. Optionality, uniqueness and also the notion of specific parameters for prototype beans are all container-related and would therefore take the conceptual burden behind ObjectFactory itself to a different level. SmartObjectFactory also serves as a way of separating those purposes.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Actually, the problem is even worse: @Autowired ObjectFactory handles share the exact same resolution rules as regular @Autowired injection points. That algorithm (and the corresponding SPI) only works towards regularly created bean instances at the moment, with no existing way to pass in construction arguments. We'll see what we can do to open this up.

[spring-projects-issues]

Frank Scheffler commented

Could you explain that a little more? I don't see, why the injection of ObjectFactory itself is a problem. As far as I know, ObjectFactory can be injected for both singleton and prototype beans. How is that going to be affected by changing the method signature (or adding a method) to the injected factory itself?

[spring-projects-issues]

Juergen Hoeller commented

It's just a problem with the current implementation arrangement. DefaultListableBeanFactory.resolveDependency and the DependencyDescriptor mechanism, as used behind @Autowired resolution, do not allow for passing in arguments at this point. That algorithm has been revised for 4.3 already, so it makes sense to tackle your arguments case as well. I'll give it a try ASAP.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Committed to master as getObject(Object... args) on SmartObjectFactory. Feel free to give it a try in an upcoming 4.3.0.BUILD-SNAPSHOT...

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Quick note: SmartObjectFactory has been renamed to ObjectProvider (extends ObjectFactory).