This commit adds reachability metadata for resources loaded by the
`GraphQlClient` and `GraphQlTester` when using the `document("name")`
API variant. This method loads the query file from the classpath at
particular locations, namely `"classpath:graphql-documents/"` and
`"classpath:graphql-test/"` with the `".graphql"` and `".gql"` file
extensions.
This commit adds the relevant resource metadata so that such resources
are loaded in the GraalVM native image at build time when the client or
the tester are reachable through the static analysis.
Fixes gh-575
Prior to this commit, using the RSocket client in a native image would
fail when setting up the codecs, if the chosen transport was WebSocket.
This is due to the fact that the `GraphQlWebSocketMessage` type was not
registered for reflection and the proper codec could not be detected as
a result.
This commit adds reflection metadata for this type.
Fixes gh-574
This commit logs the number of schema resources that were loaded to
create the GraphQL schema, at the INFO level. If DEBUG is enabled for
this package, the description of all schema resources will be logged as
well.
Closes gh-566
This commit mentions the `"application/graphql-response+json`" media
type in the reference documentation as the main media type used by the
server.
See gh-563
This commit ensures that all anchors in the reference documentation
follow a `"section.sub.title"`-like pattern to better align with the
spring-asciidoctor-backends best practices. This will allow an easier
integration with code snippets.
All rewritten anchors are listed in the anchor-rewrite.properties file
for automatic redirection.
This commit moves the configuration of a local Maven deployment
repository in a dedicated Gradle convention and applies it to all
sub-projects. This separates the publishing configuration for actual
project modules (that are meant to be published on Maven Central) from
the infrastructure sub-projects such as the documentation one.
We now provide Builder customizers to customize DataFetchers
created out of Querydsl and Query by Example repositories
by letting repositories implement customizer interfaces.
See gh-559
As of graphql/graphql-over-http#215, the official media type for GraphQL
HTTP responses is now `"application/graphql-response+json"` instead of
`"application/graphql+json"`. The latter is now deprecated and support
will be removed in the future.
This commit now favors the new media type.
HTTP Clients are still supposed to send requests with the
`"application/json"` content type.
Closes gh-563
Prior to this commit, GraphQL applications using the WebSocket transport
would fail with an `java.lang.IllegalArgumentException: No JSON Encoder`
as the JSON codec was reflecting on the `GraphQlWebSocketMessage` to
check that it can handle this type, during startup time.
`GraphQlWebSocketMessage` is the message type being used for sending and
receiving GraphQL requests. This commit registers binding reflection on
this type as soon as a `GraphQlWebSocketHandler` (mvc or webflux) is
registered as a bean in the application.
This type is also used on the client side in the client
`WebSocketGraphQlTransport`. Because clients cannot be reliably detected
here in the application context or via classpath checks, this commit
also adds a JSON metadata file that adds reflection on the type, if and
only if the `WebSocketGraphQlTransport` is reachable by the static
analysis performed by GraalVM.
Fixes gh-560
Prior to this commit, using the tracing support could result in an
NullPointerException since the instrumentation expected the tracing
propagation information to be always available from the request
extensions.
This commit improves the strategy for extracing the inbound propagation
information.
First, the instrumentation now looks up the propagation information in
the GraphQL context first, then in the request extensions as a fallback.
We ensure that no NPE can be raised if the information is missing.
Some clients might change the propagation information in the request
extensions, but in the HTTP world, most clients will send those as HTTP
headers. We are adding a new `PropagationWebGraphQlInterceptor` that can
be configured on the application to copy the relevant HTTP headers from
the HTTP request to the GraphQL context. For other transports, we
currently advise the request extensions - both WebSocket and RSocket
multiplex over the same transport message, making this approach
impossible.
Fixes gh-547
This commit ensures that the contextual names of the observations all
start with `"graphql"` (lowercase) and that all key values are prefixed
with `"graphql.*"` for a cleaner namespace.
Fixes gh-558
We no longer build the samples in the main branch due to dependency
issues between Boot starter dependencies and the project sources.
The samples really need to move out to an independent repository.
For now, this commit removes them from the main branch.
See gh-208
This change aligns with the Jakarta API requirements in Spring
Framework.
This commit also upgrades optional dependencies with the latest compatible
versions.
Closes gh-543
Prior to this commit, Spring for GraphQL would not support AOT and
GraalVM Native. Applications can perform reflection, load resources or
require JDK proxies at runtime and we need to contribute `RuntimeHints`
during the AOT phase.
This commit adds a new `BeanFactoryInitializationAotProcessor` component
that introspects GraphQL controllers and registers the relevant
reflection hints for binding on argument types and schema types.
This also registers JDK proxies for `@ProjectedPayload` support if
Spring Data Commons is present in the classpath.
Closes gh-495
This commit aligns the behavior of retrieve with its Javadoc such that
any field error, including errors on nested fields, raises a
FieldAccessException
Closes gh-499
