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

Allow applications to specify a custom set of beans rather than the default for EventListener candidates [SPR-17343] #21877

Closed
spring-projects-issues opened this issue Oct 5, 2018 · 2 comments
Labels
in: core status: duplicate

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Oct 5, 2018

Rahul Shinde opened SPR-17343 and commented

While benchmarking an application that has more than 10K+ beans, around 8 - 10 seconds was spent in identifying just the EventListener candidates during startup. 

Since we have the information for EventListener implementations beforehand, would like to provide that to avoid introspection of all other beans in the registry.

Applications can then extend EventListenerMethodProcessor and provide their own implementation that specifies subset of bean names to inspect.

 


Affects: 5.0.9, 5.1 GA

Referenced from: pull request #1980

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 5, 2018

Stéphane Nicoll commented

Juergen Hoeller I wonder if the component index couldn't be extended to pre-compute that information. Rather than providing a hook point, we could redirect this project to use the index (10K is quite a lot)

@spring-projects-issues spring-projects-issues added status: waiting-for-triage type: enhancement in: core and removed type: enhancement labels Jan 11, 2019
@snicoll
Copy link
Member

@snicoll snicoll commented Nov 24, 2021

Duplicate of #1980

@snicoll snicoll marked this as a duplicate of #1980 Nov 24, 2021
@snicoll snicoll closed this as completed Nov 24, 2021
@snicoll snicoll added status: duplicate and removed status: waiting-for-triage labels Nov 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core status: duplicate
Projects
None yet
Development

No branches or pull requests

2 participants