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

Support dynamic bean lookup a la CDI's Instance type [SPR-13132] #17723

Open
spring-projects-issues opened this issue Jun 15, 2015 · 6 comments
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jun 15, 2015

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:

3 votes, 7 watchers

@spring-projects-issues
Copy link
Collaborator Author

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

@spring-projects-issues
Copy link
Collaborator Author

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

@spring-projects-issues
Copy link
Collaborator Author

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.

@spring-projects-issues
Copy link
Collaborator Author

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 ...

@spring-projects-issues
Copy link
Collaborator Author

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.

@spring-projects-issues
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants