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

Feature Request: Scoped Bean Injection Control by Bean Creators #33393

Open
yonyes opened this issue Aug 15, 2024 · 2 comments
Open

Feature Request: Scoped Bean Injection Control by Bean Creators #33393

yonyes opened this issue Aug 15, 2024 · 2 comments
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: waiting-for-triage An issue we've not yet triaged or decided on

Comments

@yonyes
Copy link

yonyes commented Aug 15, 2024

I propose introducing a feature to Spring Framework that allows developers to specify the packages or classes where their bean can be injected. This feature aims to give bean creators more control over the injection scope, thereby enhancing application modularity and preventing misuse.

Problem Description:
Currently, all beans in an application are eligible for autowiring across the entire application. This can lead to beans being used in contexts not intended by their creators, which complicates maintenance and can lead to architectural inconsistencies.

Proposed Feature:
Implement a configuration mechanism, potentially through annotations, that enables bean creators to restrict where their beans can be injected. Unlike solutions like @Qualifier, which are controlled by the consumers, this feature would allow creators to define injection boundaries directly.

Use Cases:

  • Modular Libraries: For developers creating reusable modules intended for use in other applications, this feature would allow them to specify that certain beans should only be injectable within the module itself or in specific parts of a consuming application.

  • Large-Scale Applications: In large projects with multiple teams, it helps maintain clean boundaries and prevents architectural drift by ensuring that beans are only used in their intended contexts.

Benefits:

  • Enhanced Modularity: Provides developers with the tools to enforce modular design principles effectively.

  • Reduced Errors and Confusion: Helps prevent the misuse of components, which can reduce errors and streamline developer onboarding.

I believe this feature would significantly improve developers' control over their applications, making the Spring Framework even more robust for large-scale projects and modular library development.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Aug 15, 2024
@a-e-tsvetkov
Copy link

You can limit visibility of your bean interface with module declaration.
You can't inject bean if its interface isn't accessible. Well, technically you can with referencing them by name, but you can't do it by mistake.

@yonyes
Copy link
Author

yonyes commented Aug 19, 2024

You can limit visibility of your bean interface with module declaration.
You can't inject bean if its interface isn't accessible. Well, technically you can with referencing them by name, but you can't do it by mistake.

Thank you for suggesting Java module declarations to control bean visibility. While effective at managing package access between modules, the adoption of Java modules is inconsistent, particularly in large or legacy codebases. Moreover, not all Java libraries and frameworks fully support modularization, which can limit their practical use.

It's also important to note that beans in Spring are often autowired by type rather than through interfaces, which Java modules might not sufficiently restrict within the same module. This can lead to broader access than intended, even with modularization in place.

I propose a feature in Spring Framework that allows for granular control over bean injection, directly through Spring configuration. This would enable developers to restrict bean injection both across and within modules, enhancing modularity and preventing unintended bean usage. This feature would support both environments using Java modules and those that do not, helping to maintain clean architectural boundaries and prevent confusion in projects with multiple teams.

@jhoeller jhoeller added the in: core Issues in core modules (aop, beans, core, context, expression) label Aug 20, 2024
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) status: waiting-for-triage An issue we've not yet triaged or decided on
Projects
None yet
Development

No branches or pull requests

4 participants