At the request of the Spring Boot team, ApplicationContextFailureProcessor
implementations are now loaded via the spring.factories mechanism
instead of supporting a single processor registered via subclasses of
AbstractTestContextBootstrapper.
This makes the retrieval and handling of processors internal to
DefaultCacheAwareContextLoaderDelegate, while simultaneously supporting
multiple processors that can be registered by anyone (i.e., not
limited to projects that implement custom TestContextBootstrappers).
See gh-28826
Closes gh-29387
For a Spring Boot test, Logback logs at DEBUG level by default until
Spring Boot's logging infrastructure has a chance to take control, and
this can result in a considerable amount of INFO and DEBUG output.
It's not the number of lines that causes an issue. Rather, it's the
amount of information in each line that can become overwhelming,
especially when the MergedContextConfiguration is complex.
The main reason for lengthy DEBUG logging in a Spring Boot test is that
Spring Boot's ImportsContextCustomizer implements toString() which
results in logging of the fully qualified class names of all imported
configuration classes. In an example using @WebMvcTest, this resulted
in logging of 27 imported classes twice. However, the lists of
registered TestExecutionListener, ContextCustomizerFactory, and
ContextCustomizer implementations are also logged separately, and that
adds quite a bit of noise at DEBUG level.
This commit addresses these issues and simultaneously completely
revises logging within the Spring TestContext Framework (TCF).
- Numerous log statements are now logged at TRACE level instead of
DEBUG.
- Numerous log statements now have two modes. When logging at TRACE
level, fully qualified class names (or the results of invoking
toString() on related components) are included. When logging at DEBUG
level, simple names of classes are logged and the results of invoking
toString() on related components are omitted.
- toString() implementations in TCF components are now based on the
newly introduced SimpleValueStyler for ToStringCreator.
The combination of the above changes greatly reduces the amount of
DEBUG logging output in the TCF, but users can still access complete
details by switching to TRACE level logging.
Closes gh-29229
DefaultValueStyler hard codes conventions for styling that are verbose
and do not align well with standard toString() implementations in the
JDK for arrays, collections, and maps. Furthermore, the default styling
for classes and methods may not be suitable or desirable for certain
use cases.
To address these shortcomings, this commit introduces a
SimpleValueStyler for use with ToStringCreator. The default behavior of
SimpleValueStyler aligns with toString() implementations for arrays,
collections, and maps in the JDK, and styling for classes and methods
is configurable via a dedicated constructor.
Closes gh-29381
The `style(Object)` method in DefaultValueStyler delegates to several
internal methods. Prior to this commit those methods were private,
which prevented users from extending DefaultValueStyler without
rewriting most of the functionality.
This commit addresses this by making those methods protected so that
DefaultValueStyler can be extended. In addition, this commit introduces
protected methods for styling null, strings, classes, methods, and
objects that are not covered by any of the other style*() methods.
Closes gh-29380
LeakAwareDataBufferFactory#checkForLeaks automatically waits up to 5
sec for buffers to be released, which could be used as a way of
awaiting on some async logic to complete, and as long as buffers are
released, it shouldn't be long. However, the leak test in
LeakAwareDataBufferFactoryTests actually expects to find a leak, and
always ends up waiting the full 5 seconds.
This change, makes the wait configurable, with the no-arg method
using 0 (no waiting). AbstractLeakCheckingTests uses 1 second by
default since ResourceRegionEncoderTests did fail locally. If more
tests need this, we can adjust the settings.
This commit copies and adapts the logic from
DefaultListableBeanFactory#findMergedAnnotationOnBean
private method to make it suitable for returning multiple
annotations found in the type hierarchy in order
to support this use case with @ImportRuntimeHints.
Closes gh-29361
Conditional requests using "If-Unmodified-Since" headers are generally
used as precondition checks for state-changing methods (POST, PUT,
DELETE). See https://datatracker.ietf.org/doc/html/rfc7232#section-3.4
The spec also allows for idempotent methods like GET and HEAD.
Prior to this commit, the "If-Unmodified-Since" processing done in
`checkNotModified` (see `ServletWebRequest` and
`DefaultServerWebExchange`) would only focus on the state changing
methods and not take into account the safe methods. For those cases, the
"ETag" and "Last-Modified" would be missing from the response.
This commit ensures that such headers are added as expected in these
cases.
Fixes gh-29362
In some cases, the default response status of a `ServerWebExchange` can
be `null`, especially when the response is not available or the server
implementation does not set a default response status.
This commit ensures that the status code is available when deriving
`KeyValue` information from it, or uses a fallback value for the key
value.
Fixes gh-29359
The observation context relies on request and response for propagation,
but the exchange itself holds attributes and locale context so this is
needed for keyvalues extraction in general.
This commit adds a getter to expose the exchange from the context.
Update `ServerHttpObservationFilter` to check if the `Observation`
is a no-op before adding the `ServerRequestObservationContext`.
Prior to this commit, if the `Observation` is a no-op then the
context type added with the `CURRENT_OBSERVATION_CONTEXT_ATTRIBUTE`
would not be a `ServerRequestObservationContext`. This would mean
that `findObservationContext` would throw a `ClassCastException`.
Fixes gh-29356
This new GraalVM feature replaces ConstantFieldFeature and
introduces various enhancements:
- Leverage the new FieldValueTransformer API
- Use GraalVM 22.3 graal-sdk dependency instead of svm one
- Avoid using internal GraalVM APIs
- No need to configure JPMS exports
- Directly integrated in spring-core module
- Simplified build configuration
Closes gh-29081
Closes gh-29080
Closes gh-29089
This commit makes sure that a `ScopedProxyFactoryBean` is exposed in the
container, rather than its underlying proxy. Previously, any lifecycle
method that the proxy target exposed were invoked in the container.
This is a complementary fix to gh-29335
At present, creating LoggingCacheErrorHandler with custom logger requires use of Commons Logging API, as the appropriate constructor expects org.apache.commons.logging.Log instance. As Commons Logging is rarely the logging framework of choice in applications these days, interaction with its API might not be desirable.
This commit adds LoggingCacheErrorHandler constructor that accepts logger name and thus avoids leaking out any details about the underlying logging framework.
Prior to this commit, the `ServerHttpObservationFilter` would set the
response status (and possibly overwrite it) in case an exception is
found as an attribute.
While the exception itself should be used in the observation, the filter
should have no side effect on the response.
Fixes gh-29353
This commit upgrades Jackson to 2.14.0-rc2, and uses the new
ByteBufferFeeder in Jackson2Tokenizer.
Unfortunately, because of https://github.com/FasterXML/jackson-core/issues/478,
we had to change the CompilerConventions to suppress class file warnings.
Closes gh-29343
