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
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
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
DataBinder is not a great fit to bind GraphQL arguments which
are essentially a (structured) map of maps and collections, rather
than a (flat) map of property values with JavaBean paths.
We already navigate recursively the GraphQL arguments map, which
corresponds to the target Object structure, creating values, so all
we have to do is check for matching bean properties at each level
and set them.
See gh-516
This commit ensures a single method is used to bind raw values,
whether those a top level argument value, or a value nested within a
collection or map.
See gh-449
Before this commit, we supported binding to a higher level object,
or a scalar, or a List of either, but not to a Map of either, which
requires similar support as what we have for a List, i.e. creating
the target Map and populating it in a recursive manner.
This commit adds that support.
Closes gh-449
Prior to this commit, metrics instrumentation was provided by Spring
Boot, using Micrometer metrics. The `Instrumentation` would publish two
timers and a counter, but would not support tracing.
This commit replaces the former with a dedicated support in Spring for
GraphQL directly. This uses the new `Observation` API from Micrometer
and publishes two observations:
* a request execution observation, with timing and tracing included
* a data fetching observation with the request execution as a parent
observation
Closes gh-501
