Allow other strategies than META-INF/spring.factories for configuring Spring Boot infrastructure

[sdeleuze]

In order to make Spring Boot a better citizen with GraalVM native image generation, in Spring Fu I would like to replace META-INF/spring.factories mechanism by a custom way to provide ApplicationContextInitializer, ApplicationListener, PropertySourceLoader, EnvironmentPostProcessor and SpringApplicationRunListener instances. But SpringFactoriesLoader usage is currently impossible to disable. I think @dsyer have also a similar need.

In my use case, the functional configuration provided by the user will be used to provide the implementations. This will make the configuration more modular and will make Boot infrastructure a better citizen with GraalVM native image which requires currently a huge mount of reflection configuration because these classes are defined in a property file invisible to GraalVM static code analysis.

In term of software design, I tend to think providing constructors or setters where one can provide a list of instances instead of using internally META-INF/spring.factories, and making SpringFactoriesLoader only the default way to get implementations for those classes would improve testability, extensibility, and would make dependencies more explicit.

I am also wondering if such improvement could be used to replace SpringFactoriesLoader (which was initially designed to customize Spring Framework internals for Scala support if I am not mistaken) by another mechanism like Java ServiceLoader which is natively compatible with GraalVM native image.

[philwebb]

I think there are maybe a few different requirements in this issue that we need to clarify or possibly split out.

In order to make Spring Boot a better citizen with GraalVM native image generation, in Spring Fu I would like to replace META-INF/spring.factories mechanism.

Do we need to totally replace spring.factories in order to have it work with GraalVM? Is the Java ServiceLoader the only way to offer this kind of extensible behavior? We can certainly consider switching to it for some of the things we currently load, but:

• Not all items in spring.factories are currenlty an implementation of something (for example auto-configuration classes are keys on the annotation class)
• We don't always want to instantiate instances (for example, auto-configuration needs to use ASM parsing)
• We can't just drop existing support

SpringFactoriesLoader usage is currently impossible to disable. I think @dsyer have also a similar need.

Is this a different requirement? Which specific usages do you need to disable and why?

GraalVM native image which requires currently a huge mount of reflection configuration because these classes are defined in a property file invisible to GraalVM static code analysis

Are there any other options before we consider a wholesale migration to a different mechanism? Perhaps GraalVM should offer an extension mechanism that would allow us to make it aware of the information without needing an additional configuration?

In term of software design, I tend to think providing constructors or setters where one can provide a list of instances instead of using internally META-INF/spring.factories, and making SpringFactoriesLoader only the default way to get implementations for those classes would improve testability, extensibility, and would make dependencies more explicit.

This is a good point, although I'm not sure it's always possible since we need a way to decouple things. For example, spring-boot-autoconfigure contributes an ConditionEvaluationReportLoggingListener which is picked up by SpringApplication. We can't directly call SpringApplication.setListeners because it's the user that creates the SpringApplication instance. We also don't really want a SpringApplication subclass specifically for auto-configured applications. We need a way for modules to contribute items without the thing that they contribute them too needing to know about them.

I am also wondering if such improvement could be used to replace SpringFactoriesLoader (which was initially designed to customize Spring Framework internals for Scala support if I am not mistaken) by another mechanism like Java ServiceLoader

I wasn't aware of the history of SpringFactoriesLoader, but I'm not sure that that should sway our decision to migrate away from it. Migrating could be an option but we'll probably need to support spring.factories for some time to keep existing code compatible. I also imagine that there are other users of SpringFactoriesLoader that will need to migrate if that's really the only option to get GraalVM support.

[dsyer]

An example of the problem I think we need to address is that SpringApplication always reads spring.factories in its constructor. It's impossible to override that. It's just a bit too hard to test and/or change. Having a place where we can choose the strategy to contribute list of ApplicationContextInitializer, ApplicationListener, etc. and make spring.factories just the default strategy would help.

So something as simple as protected method in SpringApplication would not be enough, but on the right track. I have been playing with a proof of concept with a customizer interface and an annotation that you can put on your @SpringBootApplication class. (That way tests will pick it up as well, eventually, if we also modify the test context loader). So a user writes public class

@SpringBootApplication
@CustomizedWith(SpringFooCustomizer.class) 
public class MyApplication {...}

And SpringApplication notices this and uses SpringFooCustomizer instead of the default for creating listeners and initializers. In my PoC the customizer can also itself be annotated as @CustomizedWith, so it's easy to compose and inherit the defaults if you want to without the user app having to refer to them directly.

[sdeleuze]

I want to clarify that this issue is about making Boot infrastructure configurable with other strategies than using META-INF/spring.factories for configuring its infrastructure. I am not asking a concrete alternative for it (yet).

That would enable experimenting on other flavors like ServiceLoader, @dsyer @SpringApplicationCustomizers, or Spring Fu functional approach where configuration is explicitly done by the user via a DSL that will provide suppliers of listeners, initializers, etc.

I mentioned GraalVM as a concrete use case for such approach. In such native world, ASM parsing is not an option, ServiceLoader is supported by default so may be worth to try, and programmatic configuration can be analyzed by GraalVM compiler, unlike property based class configuration like META-INF/spring.factories. I am currently trying to identify if there are other pluggable mechanisms that could fit our need, and will explore that possibility as well.

SpringFactoriesLoader is currently mandatory because used in:

• SpringApplication constructor and SpringApplication#run()
• ConfigFileApplicationListener#loadPostProcessors and ConfigFileApplicationListener.Loader#Loader
• FailureAnalyzers constructor
• TemplateAvailabilityProviders constructor
• etc.

What I would like is a more flexible approach where those classes can be configured by providing List<ApplicationContextInitializer> or List<ApplicationListener> without relying on SpringFactoriesLoader for their implementation, and allow a library/framework/application/test which does not use org.springframework.boot package to provide these List<ApplicationContextInitializer> or List<ApplicationListener> which another mechanism with some extension point to be decided. Having to extend Spring Boot classes to override protected method would be fine to me or any kind of mechanism that does not force me to modify classes like SpringApplication or ConfigFileApplicationListener and duplicate a lot of code.

[wilkinsona]

It's not clear that the benefits on offer here justify the time it'll take to implement. The opportunity cost is too high at the moment.

[dsyer]

What? But we had a prototype and a plan to improve it. The cost of implementation is not high, is it? Or was there something missing?