Docs related to gh-33280 (log correlation) and
gh-35593 (application name in each log line) need some polishing:
- Fix project names
- Show how to avoid having the application name duplicated in logs
- Call out that a trailing space is needed in the correlation pattern
Closes gh-36035
See gh-33280
See gh-35593
Update Logback and Log4J2 so that they include the application name on
each log line. If `spring.application.name` had not been set, or if
`logging.include-application-name` is `false` then the name is not
logged.
Closes gh-35593
Add support for logging correlation IDs with Logback or Log4J2 whenever
Micrometer tracing is being used.
The `LoggingSystemProperties` class now accepts a defualt value resolver
which will be used whenever a value isn't in the environment. The
`AbstractLoggingSystem` provides a resolver that supports the
`logging.pattern.correlation` property and will return a value whenever
`LoggingSystem.EXPECT_CORRELATION_ID_PROPERTY` is set.
Using `LoggingSystem.EXPECT_CORRELATION_ID_PROPERTY` allows us to
provide a consistent width for the correlation ID, even when it's
missing from the MDC.
The exact correlation pattern returned will depend on the `LoggingSytem`
implementation. Currently Logback and Log4J2 are supported and both
make use of a custom converter which delegates to a new
`CorrelationIdFormatter` class.
Closes gh-33280
Update `ReactorClientHttpConnectorFactory` to that SSL configuration
is applied in addition to any configured mappers.
Prior to this commit, SSL configuration would prevent configured
mappers from being applied.
See gh-35914
In Spring Framework 5.x with Jetty 9, the reactive
JettyRequestUpgradeStrategy was able to initialize Jetty's WebSocket
infrastructure itself. With Jetty 10 this is no longer possible and
Boot must perform the initialization as part of preparing the
reactive JettyWebServer.
This commit updates the reactive WebSocket auto-configuration to
initialize Jetty's WebSocket infrastructure as part of creating the
reactive JettyWebServer.
Fixes gh-33347
Gradle 7.3.3 does not support Java 20 so the test that verifies that
the plugin fails fast when running on a version of Gradle that it
does not support needs to be disabled on Java 20 and later.
See gh-35931
