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 https://github.com/spring-projects/spring-boot/issues/42066 and https://github.com/spring-projects/spring-boot/issues/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 https://github.com/spring-projects/spring-boot/issues/44792.
  • it would be possible to enable certain Testcontainers features only in dev or test mode, in the case of the suggestion in https://github.com/spring-projects/spring-boot/issues/46367
  • it would be possible to configure certain properties only in dev or test mode. See https://github.com/spring-projects/spring-boot/issues/13332
  • it would offer a way to partly address https://github.com/spring-projects/spring-boot/issues/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 https://github.com/spring-projects/spring-boot/issues/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

Comment From: 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.

Comment From: 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?