This commit ensures that the matching path pattern for the request being
observed is used in the conytextual name, as advised in the OTel HTTP
server semantic conventions.
If the path pattern is not available, no additional value is provided
and the "http {method}" baseline is being used.
Fixes gh-29424
This commit fixes the observation instrumentation for the reactive HTTP
server by setting the best matching pattern determined by the web
framework into the `ServerRequestObservationContext`.
This information is required by the observation convention for creating
the expected `KeyValue` for the matching pattern. Prior to this commit,
the information was missing and resulted in an UNKNOWN key value.
Fixes gh-29422
Prior to this commit, the ServerHttpObservationFilter would not add
the current observation as a key in the Reactor context, preventing
from being used or propagated during the HTTP exchange handling.
Also, the client instrumentation in `DefaultWebClient` would start
the observation once the request is fully formed and immutable,
preventing the context from being propagated through HTTP request
headers.
This commit fixes both uses cases now by:
* adding the current observation as a key in the reactor context
on the server side
* using the `ClientRequest.Builder` as a Carrier on the client side
Closes gh-29388
This commit ensures that the ConsumesRequestCondition and
ProducesRequestCondition use a case insensitive check when comparing
parameters.
Closes gh-29416
This commit aligns the Artifactory configuration with the changes
applied in gh-29417.
In order to be deployed, docs artifacts must have specific properties
attached to them.
See gh-29417
This commit creates a new "framework-docs" module, which is dedicated to
documentation generation (reference and API docs).
This commit refactors the build configuration and moves the asciidoc
files to a separate location, but does not change the name nor the
nature of published artifacts.
Closes gh-29417
This commit makes sure that PartEvents with empty data buffer are
filtered out before written. Empty buffers caused issues with the
JdkClientHttpConnector.
Closes gh-29400
Add protected, convenience method in ResponseEntityExceptionHandler
to create a ProblemDetail for any exception, along with a
MessageSource lookup for the "detail" field.
Closes gh-29384
When a hint such as `graphql/*.*` is registered for resources that are
looked up via classpath scanning using a pattern such as
`classpath*:graphql/**/*.graphqls`, an appropriate pattern is in fact
registered in the generated `resource-config.json` file for GraalVM
native images; however, classpath scanning fails since GraalVM
currently does not make the `graphql` directory automatically available
as a classpath resource.
This can be very confusing and cumbersome for users since a file such
as `graphql/schema.graphqls` will not be discovered via classpath
scanning even though the file is present in the native image filesystem.
To address this, this commit automatically registers resource hints for
enclosing directories for a registered pattern.
If the GraalVM team later decides to perform automatic directory
registration, we can then remove the code introduced in conjunction
with this issue.
Closes gh-29403
Prior to this commit, it was not possible to register the root
directory as a native image resource; however, it is necessary to be
able to register the root directory to enable classpath scanning of the
root directory within a native image -- for example, to support
resource patterns such as `classpath*:/*.properties`.
This commit therefore relaxes the precondition check in the
ResourcePatternHint constructor to allow explicit registration of the
root directory.
Closes gh-29402
As can be seen in a modified version of the following example project,
attempting to access a resource discovered via classpath scanning
within a GraalVM native image -- for example via the Files.exists(...)
invocation in FileSystemResource -- currently results in a
ClosedFileSystemException since PathMatchingResourcePatternResolver
explicitly closes the native image FileSystem that backs `resource:`
resources.
Sample project: https://github.com/joshlong/spring-boot-3-aot-graphql
To address this issue, this commit removes the explicit close()
invocation for custom FileSystems after classpath scanning in
PathMatchingResourcePatternResolver.
See https://github.com/spring-projects/spring-graphql/issues/495
Closes gh-29397