Previously, the restart initializer that enables restart when
-Dspring.devtools.restart.enabled=true is set had no effect when the
ClassLoader's name did not contain AppClassLoader. This commit updates
RestartApplicationListener to use the correct RestartInitializer when
the system property has forcibly enabled restart.
When restart is enabled a SilentExitException is thrown and it should be
caught and handled by the SilentExitExceptionHandler. When the
application is invoked via one of the loader's LauncherClasses
reflection is used and this exception becomes wrapped in an
InvocationTargetEception. Previously, this wrapping prevented
SilentExitExceptionHandler from handling the exception. This commit
updates the handler to look for an InvocationTargetException with a
SilentExitException target in addition to continuing to look for a
SilentExitException directly.
Fixes gh-24797
Previously, when an authenticated Docker builder registry was
configured in the Maven or Gradle plugin and the builder and run
images specified different registries, the authentication credentials
would be sent to both registries. This could cause confusion if both
registries don't recognize the same credentials. This commit enforces
that both images are in the same registry when authentication
is configured.
Fixes gh-24552
Throw an `InvalidConfigDataPropertyException` if bad properties are
detected in profile specific files. The following properties will now
trigger an exception if used in a profile specific file:
`spring.profiles.include`
`spring.profiles.active`
`spring.profiles.default`
`spring.config.activate.on-profile`
`spring.profiles`
Prior to this commit, profile based properties in a profile specific
file would be silently ignored, making them hard to find.
Fixes gh-24733
Update `DataSourceTransactionManagerAutoConfiguration` to respect
the `spring.dao.exceptiontranslation` setting. If `exceptiontranslation`
is `false` then we create a classic `DataSourceTransactionManager`
rather than a `JdbcTransactionManager`.
Fixes gh-24321
Previously, unlike the application plugin's run task, our bootRun task
ignored the project's Java toolchain. This meant that the application
was run on a JVM with the same Java version as the one being used by
Gradle itself. This could result in a failure if the application
required a more modern JVM.
This commit updates the plugin to configure the bootRun task's
JavaLauncher convention to be one derived from the project's Java
toolchain. Toolchain support was introduced in Gradle 6.7 so this is
only done when using Gradle 6.7 and later.
Fixes gh-24517
Previously, bootRun assumed that the Java version of the JVM that would
run the application would be the same as the Java version of the JVM
that is running the build. This assumption does not hold true when
Gradle's toolchain support is used to configure tasks that fork a new
JVM to use a version other than that being used by Gradle itself.
This commit updates the BootRun task to query the JavaLauncher property
when determining the version of Java on which the application will be
run. Toolchain support and the JavaLauncher property are new in Gradle
6.7. To support earlier versions of Gradle, NoSuchMethodError is caught
we continue as if no JavaLauncher has been configured and use the local
JVM's Java version.
Fixes gh-24512
Stephane Nicoll
Andy Wilkinson
Phillip Webb
Scott Frederick
Madhura Bhave