Skip to content

Allow @ConditionalOnClass to apply to spring.factories entries for listeners and initializers etc. #16880

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

Closed
dsyer opened this issue May 16, 2019 · 4 comments
Labels
status: declined A suggestion or change that we don't feel we should currently apply

Comments

@dsyer
Copy link
Member

dsyer commented May 16, 2019

The spring.factories handling in SpringApplication is encapsulated, so we could support @ConditionalOnClass on the entries without breaking anything or changing any APIs. That way we could prevent LiquibaseServiceLocatorApplicationListener (for instance) from being needed in every Spring Boot application.

Related to (or possibly workaround for): #15704.

@dsyer dsyer changed the title Allow @ConditionalOnClass to apply to spring.factories entries for listeners and initializers etc. Allow @ConditionalOnClass to apply to spring.factories entries for listeners and initializers etc. May 16, 2019
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label May 16, 2019
@philwebb
Copy link
Member

I like the idea of filtering those items out, but I'm not sure reusing @ConditionalOnClass directly would be a great fit since it has some fairly baked-in assumptions about when it's running. For example, listeners get added before the context is refreshed. Perhaps we can extract the relevant code and create a new more generic way to filter spring.factories entries.

@philwebb philwebb added the for: team-attention An issue we'd like other members of the team to review label May 16, 2019
@wilkinsona
Copy link
Member

I like the idea too. Using @ConditionalOnClass doesn't feel right to me as it's part of spring-boot-autoconfigure while SpringApplication and the various spring.factories-loaded callbacks are part of spring-boot. So, +1 for doing something with a more generic filtering mechanism.

@philwebb philwebb added type: enhancement A general enhancement theme: graal and removed for: team-attention An issue we'd like other members of the team to review status: waiting-for-triage An issue we've not yet triaged labels May 22, 2019
@philwebb philwebb added this to the 2.x milestone May 22, 2019
@sdeleuze
Copy link
Contributor

sdeleuze commented Sep 7, 2020

+1 for this issue, that would really be useful on GraalVM native side and I would love that on JVM as well.

@philwebb
Copy link
Member

philwebb commented May 4, 2022

This is quite an old issue and we're not sure if we'll need this approach anymore for native. The LiquibaseServiceLocatorApplicationListener has also been removed since the issue was raised. I think I'll close this one for now and we can reopen it if it turns out we need something like this for native.

@philwebb philwebb closed this as completed May 4, 2022
@philwebb philwebb added status: declined A suggestion or change that we don't feel we should currently apply and removed type: enhancement A general enhancement theme: native labels May 4, 2022
@philwebb philwebb removed this from the 2.x milestone May 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

No branches or pull requests

5 participants