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.
Comment From: philwebb
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.
Comment From: wilkinsona
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.
Comment From: sdeleuze
+1 for this issue, that would really be useful on GraalVM native side and I would love that on JVM as well.
Comment From: philwebb
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.