DevToolsDataSourceAutoConfiguration and DevToolsR2dbcAutoConfiguration
were only guarded by classes from the JDK and r2dbc-spi respectively.
When a single user-defined DataSource or ConnectionFactory bean was
present, their conditions went on to reference classes from
spring-boot-jdbc or spring-boot-r2dbc. Both are optional dependencies
of spring-boot-devtools, so startup failed with a NoClassDefFoundError
when they were absent.
This commit adds a class from each module to the class conditions.
Without the modules the conditions could never match, so this only
turns the failure into a back-off.
See gh-51872
Signed-off-by: Kosuke Yanagihara <11373191+ksky8864@users.noreply.github.com>
ClassLoaderFilesResourcePatternResolver.isDeleted() calls
resource.exists() and resource.getURI() inside the loop over the
uploaded files, so both are repeated once per DELETED entry although
neither depends on the entry. Every resource lookup made while the
application context is being built goes through this method - about
1300 times per restart in the application I measured - so a session
that has accumulated 100 deleted files performs around 130 000 file
system lookups where 1300 are enough.
This commit hoists both calls out of the loop: the resource is
inspected at most once per call, on the first DELETED entry, and the
URI comparison then uses the cached value. The method still returns on
the first match and still reports a failing getURI() as an
IllegalStateException, so behaviour is unchanged.
The loop now walks the per-directory entry sets, which is what
ClassLoaderFiles.addAll() and RestartServer already do, instead of the
flattened view added in gh-46289. That view is wrapped in
Collections.unmodifiableSet(), whose iterator is shared JDK code; in a
running application its delegate calls are megamorphic and C2 stops
inlining them, which made restarts with many accumulated files and no
deletions slower than before gh-46289. isDeleted() returns a boolean,
so the visiting order of the entries cannot change its result.
Measured on a Spring Boot application driven through the remote restart
path (restart request to ApplicationReadyEvent), 12 JVMs per variant
and 20 restarts per JVM, medians:
100 source directories, 10 000 entries, 10 deleted: 278 ms -> 200 ms
100 source directories, 10 000 entries, 100 deleted: 891 ms -> 201 ms
100 source directories, 10 000 entries, 500 deleted: 3536 ms -> 200 ms
100 source directories, 50 000 entries, none deleted: 431 ms -> 341 ms
100 source directories, 10 000 entries, none deleted: 202 ms -> 192 ms
no uploaded files: 150 ms -> 148 ms
See gh-51841
Signed-off-by: DongHoon Lee <dhl1924@naver.com>
DevToolsPropertyDefaultsPostProcessor looked for
ConfigurableReactiveWebEnvironment
in org.springframework.boot.web.reactive.context by name, but the class
moved to org.springframework.boot.web.context.reactive in 4.0. As a
result, reactive web applications were never identified as web
applications and the hint about setting logging.level.web to DEBUG was
not logged for them.
ConfigurableReactiveWebEnvironment is part of spring-boot, so it is now
referenced directly rather than by name. The servlet environment check
is unchanged as spring-web is an optional dependency.
See gh-51708
Signed-off-by: ohchanKyu <okc0202@naver.com>
Before deprecating `TestRestTemplate`, we must first stop using it in
module tests and replace it with:
* `RestTestClient` when the Spring MVC infrastructure is present
* `RestClient` when the test does not have Spring MVC on classpath
See gh-46632
With Spring Framework 7.1 deprecating RestTemplate for removal, this
commit deprecates our supporting infrastructure as well, and steers
users towards RestClient instead:
* RestTemplateAutoConfiguration and
RestTemplateObservationAutoConfiguration
* RestTemplateBuilder, RestTemplateBuilderConfigurer, and
RestTemplateBuilderClientHttpRequestInitializer
* RestTemplateCustomizer, RestTemplateRequestCustomizer, and
ObservationRestTemplateCustomizer
* MockRestServiceServerAutoConfiguration,
MockServerRestTemplateCustomizer, and RootUriRequestExpectationManager
in the test support module
The reference documentation no longer covers RestTemplate and now
solely documents RestClient and WebClient. Code snippets and sample
tests that only existed to illustrate RestTemplate usage have been
removed accordingly.
Closes gh-51118
This commit adapts @Nullable when calling Map#remove as it correctly
handles nullability.
See gh-50972
Signed-off-by: Manu Sridharan <msridhar@gmail.com>