Thomas Darimont opened SPR-13132 and commented

It would be helpful to be able to dynamically query an application context for beans that match a specific type and or are annotated with some specific qualifier annotations.

CDI offers support for this via javax.enterprise.inject.Instance. Currently the application context only offers to query beans by type. It would be great if we could support dynamic bean lookups via Instance<T> backed by the BeanRegistry.

I did a quick PoC here. The basic idea is to provide a custom AutowireCandidateResolver that detects Instance<T> autowire targets, identifies the actual target bean type and provides some kind of Instance adapter which performs the actual bean lookup.

Reference URL: https://github.com/thomasdarimont/spring-boot-cdi-instance-example/blob/master/src/test/java/demo/SimpleCdiInstanceAdapterTests.java#L73

Issue Links: - #16761 Add generics / parameterized type support to ListableBeanFactory getBeanNamesForType/getBeansOfType methods - #18515 An ObjectFactory variant with lenient not-unique handling - #13532 Convenient programmatic bean retrieval with qualifiers - #18529 ObjectFactory lacks method for getting bean with specified constructor arguments - #17522 Ability to query an ApplicationContext for annotations on a bean

3 votes, 7 watchers

Comment From: spring-projects-issues

Juergen Hoeller commented

On a related note, as of 4.2, we support bean lookup by ResolvableType which goes closer to this territory at least.

And with respect to CDI's Instance, this is one of the proposals for JSR-330 v2, with an EE 8 aligned target. I'd like to support that JSR-330 revision as of Spring Framework 5.0 already; it's to some degree in our hands to drive it forward.

Juergen

Comment From: spring-projects-issues

Juergen Hoeller commented

On a more recent note, 4.3 ships ObjectProvider as a richer variant of ObjectFactory, allowing for convenient lookup of optional or primary beans as well as passing arguments to prototype beans.

I guess this primarily leaves narrowing to specific beans by annotation or by subtype, as well as the lookup of all matching beans for the declared type? Do you have any concrete use cases in mind?

Juergen

Comment From: spring-projects-issues

Thomas Darimont commented

Yes, it mostly boils down to narrowing the beans by annotation / subtype - one use case is that I want to dynamically select a "strategy" among multiple candidates, which are represented as beans.

One could of course do

@Autowire List<Strategy> strategies;

but then I'd also need boilerplate code to select the default if it's just one, or match those candidates based on a predicate (e.g. if an annotation is present and has a certain configuration or not) - javax.enterprise.inject.Instance provides this via the Instance<T> select(...) method variants.

Comment From: spring-projects-issues

Jan Ortmann commented

Will this feature be available in 5.1? Our use case: We want to build a library that works with CDI and Spring ...

Comment From: spring-projects-issues

Juergen Hoeller commented

To be clear, this ticket is not about CDI API compatibility, it is about CDI-style retrieval variants within Spring's programming model. So while this might make CDI/Spring bridging more straightforward in some scenarios, I'm afraid it won't cover your use case directly.

Comment From: spring-projects-issues

Jan Ortmann commented

Thanks for the fast reply. For some historical reasons, it would come handsome if we could access all beans of a type in our library in a uniform way. (A sort of PlugIn-Mechanism). Its not an attempt to run a large codebase either on Spring or CDI. So this might help us.