`LogbackLoggingSystem` and `Log4J2LoggingSystem` install a JUL bridge
handler only when the application is not already managing `java.util.logging`.
However, `cleanUp()` removed the bridge handler whenever the bridge class
was present on the classpath, so Spring Boot uninstalled a bridge handler
that an application had installed and managed itself.
Track whether the bridge handler was installed by Spring Boot and only
remove it during cleanup when that is the case.
See gh-50779
Signed-off-by: dhruv-15-03 <dhruvrastogi2004@gmail.com>
Previously, the `entityManagerFactoryBuilder` bean method injected a
`Map<String, AsyncTaskExecutor>` to determine the fallback executor used
for background JPA bootstrapping. A `Map` parameter is resolved eagerly,
so this forced early initialization of every `AsyncTaskExecutor` bean
whenever the builder was created, even when background bootstrapping was
not in use. When an `AsyncTaskExecutor` directly or transitively
depended on the `EntityManagerFactory`, this resulted in a
`BeanCurrentlyInCreationException`.
The fallback executor is now resolved lazily.
`EntityManagerFactoryBuilder` holds a `Supplier` that is only invoked
when background bootstrapping is actually required, and the executor is
then looked up from the `BeanFactory` rather than eagerly injected. A
new `Supplier`-based constructor is added for this purpose; the existing
constructor that accepts an `AsyncTaskExecutor` is retained and
delegates to it.
The same eager `Map<String, AsyncTaskExecutor>` injection, along with an
unused private method, is also removed from
`DataJpaRepositoriesAutoConfiguration`.
See gh-50801
Signed-off-by: Ns <397827222@qq.com>
Move the reactive Cloud Foundry health endpoint extension into a
health-specific configuration guarded by @ConditionalOnClass. When
spring-boot-health is absent, scanning the outer configuration attempts
to resolve ReactiveHealthEndpointWebExtension and causes context refresh
to fail.
See gh-50916
Signed-off-by: Lee JiWon <dlwldnjs1009@gmail.com>
ExportedLayers left the intermediate create-builder-scratch-source
temp file behind after rebased layer files were written, and opened
layer InputStreams without closing them when StreamUtils.copy does
not close either stream. Delete the source temp in a finally block
and use try-with-resources for the apply path so layer files can be
deleted reliably.
See gh-50919
Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>
* dependabot/github_actions/gradle/actions/setup-gradle-6.2.0:
Polish "Bump gradle/actions/setup-gradle from 5.0.2 to 6.2.0"
Bump gradle/actions/setup-gradle from 5.0.2 to 6.2.0
Closes gh-50890