Prior to this commit, the `RestTemplate` `ClientHttpObservation` would
be started before the request object is available. While this would also
measure the connection estalishment for some HTTP client libraries, this
arrangement is incompatible with a tracing approach where the request
must be available to propagate information through the request headers.
This commit ensures that the observation only starts when the request is
available.
Fixes gh-29234
Prior to this commit, the HTTP Observations would use
`HttpStatus.Series` as a value source for the "outcome" key value in
recorded observations. This would work for most cases, but would not
align in the 2xx HTTP status cases: the series would provide a
"SUCESSFUL" value whereas the heritage metrics support in Spring Boot
would give "SUCESS".
This commit introduces a dedicated `HttpOutcome` concept for this and
applies it to all HTTP observations.
Fixes gh-29232
This commit ensures that all HTTP `ObservationConvention`
implementations provide a consistent contextual name for observations.
This name should be like "http get" where only the HTTP verb changes
depending on the request.
Fixes gh-29231
This commit adds the necessary infrastructure to process an application
using the AOT engine, similar to the existing TestAotProcessor for
processing tests.
This can be used by frameworks built on top of Spring Framework, for
instance by providing a main method that can be triggered by build
tools.
Close gh-29181
Commit 0eb66789ed which introduced generic FileSystem support in
PathMatchingResourcePatternResolver also introduced a regression in that
a matching folder is now returned in the results.
This commit address this by additionally using Files#isRegularFile() in
the predicate used to filter candidates.
Closes gh-29163
Before this commit, beans registered with the Kotlin bean DSL
typically added via SpringApplication#addInitializers
were registered 2 times: by the code generated AOT and by
the listener executed at runtime.
After this commit, such beans are only registered 1 time when
AOT generation is involved, and does not require specific
reflection hints on native execution anymore.
Closes gh-29211
This commit also temporarily changes a test assertion for the Jackson
Kotlin module.
As of https://youtrack.jetbrains.com/issue/KT-52932, Kotlin enhanced the
`IntRange` and this change is not supported yet by the Jackson Kotlin
module. An issue has been reported here:
FasterXML/jackson-module-kotlin#582
Closes gh-29225
Replace the `ApplicationContextAotInitializer` class with an
`AotApplicationContextInitializer` interface so that its use can be
detected using a simple `instanceof` check. The existing functionality
has been moved to a factory method on the interface allowing:
`new ApplicationContextAotInitializer()
.initialize(context, names);`
To now be written as:
`AotApplicationContextInitializer.forInitializerClasses(names)
.initialize(context);`
See gh-29157
The upgrade to SLF4J 2 via gh-29152 has broken
ConstantFieldSubstitutionProcessor when the class processed
has both a static boolean field to make constant at build
time and a static logger.
This issue is about catching and logging those errors,
skipping the processing of such fields which will be
then evaluated at runtime.
Closes gh-29219
Improve ResponseCookie to allow an existing instance to be mutated
and also to set the cookie value through the builder. This allows
CookieLocaleResolver to avoid duplicating all the fields of
ResponseCookie and to have only a ResponseCookie field instead.
Closes gh-28779
At present, CookieLocaleResolver extends CookieGenerator instead of
AbstractLocale(Context)Resolver like other LocaleResolver
implementations. This means it duplicates some common aspects of
LocaleResolver hierarchy while also exposing some CookieGenerator
operations, such as #addCookie and #removeCookie.
Additionally, CookieGenerator's support for writing cookies is based
on Servlet support which at current baseline doesn't support SameSite
directive.
This commit refactors CookieLocaleResolver to make it extend
AbstractLocaleContextResolver and also replaces CookieGenerator's
cookie writing support with newer and more capable ResponseCookie.
Simplify creation of CookieLocaleResolver with custom cookie name
This commit introduces CookieLocaleResolver constructor that accepts
cookie name thus allowing for a simpler creation of an instance with
the desired cookie name.
See gh-28779
This commit introduces support in PathMatchingResourcePatternResolver
for resolving files in a generic fashion using the
java.nio.file.FileSystem API, including preliminary support for class
path scanning within a GraalVM native image.
See included commits for details.
Closes gh-29163
The JDK has decent support for walking a file system (via the
FileSystem API in java.nio.file), but prior to this commit Spring still
used hand-rolled pre-Java 7 code. Also, in principle, FileSystem can be
an abstraction used to express any hierarchy of resources through their
URIs. This is a good fit with the Spring Resource abstraction, and for
instance would mean that GraalVM native images could potentially do
classpath scanning through a custom URI and FileSystem already provided
by GraalVM.
In light of the above, this commit overhauls the implementation of
PathMatchingResourcePatternResolver to use a java.nio.file.FileSystem
to find matching resources within a file system.
As a side effect, several obsolete `protected` methods have been
removed from PathMatchingResourcePatternResolver.
See gh-29163
This commit improves GeneratedClass to support inner classes, allowing
them to be registered by name with a type customizer, as
GeneratedClasses does for top level classes.
BeanDefinitionMethodGenerator leverages this feature to create a
matching structure for configuration classes that contain inner classes.
Closes gh-29213
New methods in DefaultResponseCreator for adding headers and cookies,
for specifying the character encoding when setting a string body on
a response, which is useful when working in environments that do not
automatically assume UTF-8, such as integrating with legacy
applications from a new Spring one.
New methods in MockRestResponseCreators support extra commonly used
HTTP status codes, including some that occur when working in AWS,
CloudFlare, or when using gateways such as Kong, where resilient
applications should be able to respond to ratelimits, gateway errors,
and gateway timeouts that may occur if a remote service is down.
Added test cases for any changes made.
See gh-27280