spring-projects / spring-projects/spring-boot
Identifying the bootstrap mode of a Spring Boot application
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 81.5k
- Forks
- 42.7k
- Avg merge
- 2d 4h
- Merged PRs (30d)
- 65
Description
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:
devmode, when running the application as part of a development workflow (e.g. from Gradle'sbootRun,bootTestRun, or from an IDE)testmode, when running auto testsprodmode (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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing spring-boot-devtools/src/main/java/org/springframework/boot/devtools/system/DevToolsEnablementDeducer.java and the Spring Boot Gradle and Maven plugin entry points mentioned in the proposal. Clarify the bootstrap-mode contract and how development, test, and production cases are distinguished; done requires an agreed design spanning the relevant core and plugin behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, spring-boot
- Domain
- developer-experience
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100