Refactor `*ExportConfiguration` classes to be regular auto-configuration
classes.
Also removed the `@ConditionalOnProperty` guards for `.enabled` properties
since auto-configuration can now be excluded in the usual way. Enabled
properties remain where applicable and are adapted for Micrometer to use
as it sees fit.
Fixes gh-11838
Update `GitProperties` so that the `commit.id` entry is also copied to
`commit.id.full`.
Prior to this commit, when returning full details, the value of
`commit.id` would be replaced with a `Map` containing only `abbriv` as
a key. By copying the value to a sub-key we ensure that it remains
available both in the FULL and SIMPLE modes.
Fixes gh-11892
This change updates SqlDialectLookup to delegate to jOOQ's JDBCUtils
rather than creating an additional mapping between
org.springframework.boot.jdbc.DatabaseDriver and org.jooq.SQLDialect.
This has the following advantages:
1. jOOQ's `SQLDialect` to URL mappings are already maintained by jOOQ,
so no additional changes will be necessary to Spring Boot in the
future.
2. Delegating to jOOQ means that the mapping also works for the
commercial jOOQ distributions, e.g. when working with DB2, Oracle,
SQL Server, etc., as the JDBCUtils of the commercial distribution
also contains the relevant logic to map to e.g. `SQLDialect.DB2`,
`SQLDialect.ORACLE`, `SQLDialect.SQLSERVER` (which are not
available from the open source distribution linked by Spring Boot
by default).
Closes gh-11466
The fix in Spring Data Redis for sentinel configuration means that
two Jedis sentinel tests now attempt to connect to a Sentinel. As a
result the tests fail. Running a Redis Sentinel in a Docker container
appears to be non-trivial. As an alternative, this commit updates the
tests to capture the JedisConnectionFactory prior to its
initialization (which is the failure trigger) and then assert that its
configuration is as expected.
See gh-11884
Closes gh-11855
Update `AbstractHealthIndicator` so that the warning message can be
customized. Also updated our existing indicators with better messages.
Fixes gh-11880
Move `ApplicationHome`, `ApplicationPid` and `ApplicationTemp` to the
`system` package. Since `system` package is now much lower level, the
existing `FileWriter` implementations also needed to move to prevent
package tangles.
Fixes gh-8614
Add a new `WebServerApplicationContext` interface that provides a common
abstraction for all application contexts that create and manage the
lifecycle of an embedded `WebServer`.
Allows server namespaces to become a first-class concept (rather
subverting `ConfigurableWebApplicationContext.getNamespace()`) and
allow us to drop `getServerId()` from `WebServerInitializedEvent`.
Also helps to improve `ManagementContextAutoConfiguration` and
`ManagementContextFactory`.
Fixes gh-11881
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
Madhura Bhave
Andy Wilkinson
Michael J. Simons
dreis2211
Stephane Nicoll
Jon Schneider
Phillip Webb
hanyong
Eddú Meléndez
Lukas Eder
igor-suhorukov
Johnny Lim
Tony Findeisen
Vedran Pavic
Jon Schneider
Gary Russell