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
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
