New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide a property or environment variable to enable DevTools' restarter irrespective of how the application was launched #21424
Comments
Suggested workarounds:
with a
|
I would now like to use Spring Boot 2.3.x, with skaffold and buildpacks. Wouldn't it be possible to make the Who is developing this buildpack? |
@torsten-liermann There is more information on buildpacks at https://buildpacks.io/ and https://paketo.io/. If you have any further questions, please follow up on Stack Overflow or Gitter. As mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements. |
We need first class support for inner-loop development in Kubernetes, and we need to make it as simple as possible. |
Given the inconsistency in behaviour between launching the app using its main class and a manually created classpath, and launching the app using the launcher and it determining the classpath, we've decided to treat this one as a bug and tackle it in 2.3.x. |
I'm wavering on this again. The documentation describes the current behaviour quite accurately:
Given that description it feels a bit much for a maintenance release. We may need to wait till 2.4 to change the behaviour. |
Thumbs up for 2.4 |
I wonder if we need to be a bit smarter than just enabling the restarter when DevTools is present, even if it looks like a production deployment. I'm imagining a property or environment variable that can be used to enable the restarter, irrespective of what's launched the application, and something that hooks into |
@dsyer @jorgemoralespou Any thoughts on the above? |
I think that when developer go though the hassle of skipDevtools=false in the maven pom is because they need to have devtools available, independently of where it runs. The fact that it starts by default can be considered a security issue, but the fact that it won't run in any case when in buildpacks is also a "development" issue because developers want to be able to develop in containers. It would be cool if that ENV you propose, when run from a Buildpack, could add the devtools jar and free the developer from having to tune the pom.xml or create multiple profiles. Another option could be to create 2 images when the BP detects devtools, where it produces 2 set of images with the only difference of an additional layer with the devtools.jar in that additional layer, so that developers can run the my-image:version-dev while there's also the my-image:version image that would be the one used for promotion. Just a random thoughts. In any case, I would like us to explore ways to make development of SpringBoot apps on containers on Kubernetes clusters more seamless and possible with as many tools as possible, from IDEs to CLIs. |
This workflow used to work, but now doesn't:
The problem is that
Skaffold
still notices changes and syncs them with the running container, but Spring Boot is now running from theJarLauncher
(because of a change in the default buildpack), so the changes are ignored by the app. You can see from the logs that the main thread is "main" not "restartedMain" so you know it's not going to work.To fix it you would need a system property or something that could be set to force the "restartMain" thread to be created even though the class loader is a
JarLauncher
. Or alternatively, a way to build the image with a differentMain-Class
.The text was updated successfully, but these errors were encountered: