By default, AbstractTestExecutionListeners have an order of lowest
precedence. This means that it is impossible to write a listener with
lower precedence that any listener that's using the default order.
This commit updates Boot's 6 AbstractTestExecutionListeners to order
them explicitly. MockitoTestExecutionListener performs injection of
Mockito mocks and spies into the test instance. It now has an order of
2050 giving it slightly lower precedence than the dependency injection
test execution listener (2000).
The remaining 5 listeners have all been ordered with lowest precedence
- 100. This leaves them near their current lowest precedence position
while creating some room for any listeners that require lower
precedence.
Closes gh-11796
Previously, the order of the entries in a TestJarFile was determined
by the underlying file system rather than by the order in which
they were added. This could lead to unpredicatable ordering and
failures in tests that verify archive entry ordering.
This commit updates TestJarFile to add entries to the archive in
insertion order.
See gh-11695
See gh-11696
Previously, the Repackager would write entries in the following
order:
- Libraries that require unpacking
- Existing entries
- Application classes
- WEB-INF/lib jars in a war
- Libraries that do not require unpacking
- Loader classes
Libraries that require unpacking were written before existing entries
so that, when repackaging a war, an entry in WEB-INF/lib would not
get in first and prevent a library with same location from being
unpacked. However, this had the unwanted side-effect of changing
the classpath order when an entry requires unpacking.
This commit reworks the handling of existing entries and libraries
that require unpacking so that existing entries can be written first
while also marking any that match a library that requires unpacking
as requiring unpacking.
Additionally, loader classes are now written first. They are the
first classes in the jar that will be used so it seems to make sense
for them to appear first. This aligns Maven-based repackaging
with the Gradle plugin's behaviour and with the structure documented
in the reference documentation's "The Executable Jar Format" appendix.
The net result of the changes described above is that entries are
now written in the following order:
- Loader classes
- Existing entries
- Application classes
- WEB-INF/lib jars in a war marked for unpacking if needed
- Libraries
Closes gh-11695
Closes gh-11696
Previously, the ordering of the entries in an archive produced by
BootJar was different to the ordering of the entries in an archive
produced by BootWar. The latter placed application classes before
any nested jars, whereas the former was the other way around.
This commit updates BootJar to use the same ordering as BootWar and
adds tests to verify that the ordering is the following:
1. Loader classes
2. Application classes (BOOT-INF/classes or WEB-INF/classes)
3. Nested jars (BOOT-INF/lib or WEB-INF/lib)
4. Provided nested jars in a war (WEB-INF/lib-provided)
The tests also verify that the position of a library is not affected
by it requiring unpacking.
See gh-11695
See gh-11696
Stop running apply-plugin tests as part of the build since during a
release the version number will change and the jar will not be
available.
Fixes gh-11857
Update a couple of the `spring-boot-gradle-plugin` sample gradle flies
so that they include the running classpath. The additional lines are
contained within a tag which is ultimately filtered from the final
documentation.
Fixes gh-11857
While Spring Mobile support has been removed from Spring Boot, the
auto-configuration has been relocated to a separate module that uses
the same keys.
Flagging those keys as deprecated means that the IDE will be confused
when the extra jar is present on the classpath as it advertizes, as
it should, support fo them.
Closes gh-11844
Add MeterFilter to restrict the maximum number of web client URI tags
created. Prior to this commit, if a user was manually building URIs for
use with a RestTemplate (rather than using uriVariables) the JVM could
run out of memory.
Fixes gh-11338
Co-authored-by: Phillip Webb <pwebb@pivotal.io>
Update micrometer auto-configuration so that a `CompositeMeterRegistry`
is only created when more than one `MeterRegistry` bean is declared.
When a composite is crated, it is marked as `@Primary` so that it
can be directly injected. Meter registries can now be defined directly
as beans, and auto-configuration can back off in the usual way.
The `MeterRegistryConfigurer` is now called `MeterRegistryCustomizer`
and is generically types so it's easy to apply customizations to a
particular `MeterRegistry` implementation.
Fixes gh-11799
Co-authored-by: Jon Schneider <jschneider@pivotal.io>
By default, JUL configures a single root handler. That handler is a
ConsoleHandler. Previously, we removed all root handlers from JUL but
this is problematic in environments where other handlers are
registered with JUL and those handlers need to be retained.
0679d436 attempted to fix the problem by leaving the root handlers in
place and only adding and removing the bridge handler. This resulted
in log output from Tomcat (and anything else that uses JUL) being
duplicated.
This commit makes another attempt at tackling the problem. It attempts
to detect JUL's default configuration (a single root handler that's a
ConsoleHandler) and only removes the handler if it appears to be from
the default configuration. For environments where default JUL
configuration is being used, this will prevent duplicate logging and
for environments where custom JUL configuration is being used, this
will prevent that configuration from being undone.
Closes gh-8933
Previously, the test in MetricsAutoConfigurationIntegrationTests was
testing the functionality of WebMvcMetricsFilter to verify that the
auto-configuration had registered the filter for async dispatches.
This test was complex and covered the same code as a test in
WebMvcMetricsFilterTests.
This commit reworks the test to examine the dispatcher types on the
filter registration directly instead.
Closes gh-11826
This commit makes sure that a "cache.time-to-live" property is not
generated for endpoints that do not have a main read operation (i.e. a
read operation with no parameter or only nullable parameters).
This matches the endpoint feature that provides caching for only such
operation.
Closes gh-11703
This commit enables a more flexible Liquibase/Flyway configuration by
allowing for a combination of the provider's and the primary
DataSource's configuration to be used. This gives developers the
flexibility to specify only a user or a url and having
Liquibase/Flyway fall back to individual datasource properties rather
than ignoring the Liquibase/Flyway properties and falling back to the
default data source.
See gh-11751
Add an operation on PropertyMapper that takes care of casting. Returns
a source for the requested type if the current value is of the right
type.
Closes gh-11788
There's an extra ClassLoader in the hierarchy of the TCCL in Groovy
2.4 vs Groovy 2.5 so we require an extra getParent() call to avoid
being able to load classes that are visible to the launched URL
class loader.
Closes gh-11745
Previously, the logging system was cleaned up in response to the
root context's ContextClosedEvent being received. This event is
published early in a context's close processing. As a result, the
logging system is in cleaned up state while, for example, disposable
beans are being destroyed.
This commit reworks the logic that triggers logging system clean up
to use a disposable bean instead. Disposable beans are called in
reverse-registration order. The logging clean up bean is registered as
early as possible so that it should be the last disposable bean to
be called.
Closes gh-11676
Update `@SpringBootTest` `WebTestClient` support so that the bean
definition is only registered when the user has not defined or
auto-configured their own.
See gh-10556
Update `@SpringBootTest` `TestRestTemplate` support so that the bean
definition is only registered when the user has not defined or
auto-configured their own.
See gh-10556
Move the "testdb" naming logic to `DataSourceProperties` and expose
the `deduceDatabaseName` method so they can be used in
auto-configuration.
See gh-11719
Previously, Hikari's pool name was auto-configured with the value of
`spring.datasource.name` that defaults to `testdb`, which brings some
confusion.
This commit removes the default `testdb` value on
`spring.datasource.name` as it is a sane default only for an embedded
datasource. It is applied whenever applicable instead.
Closes gh-11719
Phillip Webb
Andy Wilkinson
Madhura Bhave
dreis2211
Johnny Lim
Stephane Nicoll
Tony Findeisen
Jon Schneider
Vedran Pavic
Jon Schneider
Gary Russell
Nikolay Rybak
igor-suhorukov
Dominic Gunn
yulin
Huang YunKun
Raja Kolli