Identifying the bootstrap mode of a Spring Boot application

[ThomasVitale]

It's common to define special behaviour of a Spring Boot application based on whether it's run in development or when running tests. It would be great if Spring Boot itself would introduce a way to identify the bootstrap mode of an application:

• dev mode, when running the application as part of a development workflow (e.g. from Gradle's bootRun, bootTestRun, or from an IDE)
• test mode, when running auto tests
• prod mode (the default one) in all other cases (e.g. when the application runs from a JAR or a container image).

This feature would enable several other features:

• it would be possible to define special profiles when in dev and test mode. See Investigate developer specific profile / properties support #42066 and Investigate convention based application.properties specifically for tests #38098
• it would be possible to simplify the Spring Boot DevTools configuration for detecting whether the application is running in a text context (DevToolsEnablementDeducer.java)
• it would provide a clean and simple way for each Spring Boot module to provide configurations to be enabled only in dev-mode, solving the modularisation issue in DevTools. See Allow devtools-property-defaults.properties to be contributed by modules #44792.
• it would be possible to enable certain Testcontainers features only in dev or test mode, in the case of the suggestion in Zero-Code Dev Services with Testcontainers #46367
• it would be possible to configure certain properties only in dev or test mode. See Support DevTools override properties from custom starters #13332
• it would offer a way to partly address Investigate pluggable config data activation #23017 and activate configuration properties when a specific bootstrap mode is active (e.g. only in development environments).

There are common configurations applied in most Spring Boot projects, enabled only during development. For example, exposing all Spring Boot Actuator endpoints and making them available without authentication. It would be so useful to have that out-of-the-box whenever the application is started in dev mode. Similarly, it would be possible to start introducing a series of features aimed at improving the developer experience. For example, replacing the whitelabel error page that is so often source of confusion in developers new to Spring Boot with some useful Spring Boot landing page. Or a more useful 404 page when in dev mode (see #5545). All these features could be implemented by third parties, but the bootstrap mode detection is something that cannot be done easily by a third party without affecting the developer experience.

The Spring Boot Gradle and Maven plugins could be extended to define a certain property signalling the bootstrap mode, based on which task/goal is executed.

I tried to determine the bootstrap mode inspired by the approach used in Spring Boot DevTools, but the implementation won't be as robust as if Spring Boot itself defined such feature in its core. I used the bootstrap mode determined in that way to define profiles that enhance the developer experience (see Arconia Profiles) and for applying some customisations to Testcontainers when in dev mode (see Arconia Dev Services).

I'm available to help in any way I can regarding this feature proposal.

Thanks

[philwebb]

Thanks for the suggestion @ThomasVitale. Way way back in time I tried to look at this but the biggest hurdle I found was IDE detection. Trying to detect if an app is started from an IDE in a consistent way that works for all of them turned out to be quite hard.

We probably can't take anything more on before 4.0, but I think it's worth looking at this again sometime in the future.

[jonatan-ivanov]

I did something similar in the past, I think one way of thinking about (/implementing) this is introducing built-in dev and test profiles (on top of default). So Boot, at its core does not need to detect if it supposed to run in dev/test mode but the "user" (build/plugin, IDE, or really the user) need to tell it. Basically Boot's auto-configuration defines the "behavior" in these scenarios but it does not "activate" them.

I guess that's similar to what Arconia is doing too?

[ThomasVitale]

@philwebb thanks for considering this.

@jonatan-ivanov yes, something like that. Having the "user" specify which is the bootstrap mode is probably the most robust way of implementing this.

Some notes from my experience with Arconia:

• I introduced the concept of bootstrap mode as its own concept, decoupling it from profiles. The main reason was to have it as a more generic concept and support more use cases than just configuration (initially, I used profiles directly and met several limitations). The bootstrap mode can be one of dev, test, or prod. This bootstrap mode can be detected by Arconia via some heuristics which work fine in many cases, but not as robust as having the build/plugin, IDE or similar to specify it. (see BootstrapModeDetector)
• Any logic that needs to be activated only in dev or test mode can do so by retrieving the current bootstrap mode, without having to taking profiles into account (i.e. no need to access the Spring Context, it's just a static method call). That's what the Arconia Dev Services do to share containers only in dev mode (more info here).
• Arconia supports specifying the bootstrap mode via a JVM System Property, meant to be used by build/plugin, IDE or similar. When not set, the heuristics mentioned above are used. This property is set by the Arconia CLI when running commands like arconia dev and arconia test (feature available in the upcoming release of Arconia CLI).
• Whenever a dev or test bootstrap mode is detected, a dedicated profile is activated by default (respectively dev and test). More info here. Some considerations about this feature:
  • The activation of bootstrap mode-related profiles can be disabled via a configuration property. There can be cases where developers don't want the bootstrap profiles to be enabled, for different reasons.
  • By default, the dev bootstrap mode will trigger the activation of a dev profile. However, that is not necessarily desired by developers, which might be using the dev profile for other goals or even use a different profile for development-only configurations. For that reason, it's possible to customise the profiles (more than one is possible) to activate in dev mode.
  • By default, the test bootstrap mode will trigger the activation of a test profile. However, that is not necessarily desired by developers, which might be using the test profile for other goals or even use a different profile for test-only configurations. For that reason, it's possible to customise the profiles (more than one is possible) to activate in test mode.
  • Initially, I also had the prod bootstrap mode trigger the activation of a prod profile. After getting feedback from developers, I removed this feature since it turned out to be not very useful and in some cases problematic since developers might already be using profiles like staging, preprod and prod in their environments, which would all map to the prod bootstrap mode, but not all to the prod profile.
  • The feature for activating profiles based on bootstrap modes doesn't support Spring Cloud Config, whose integration operates before Arconia can set those profiles. This is something I'm still trying to sort out. The way I set profiles now is via an EnvironmentPostProcessor (see BootstrapEnvironmentPostProcessor).