Reflect jakarta classifiers for Querydsl annotation processing. Also, update to Java 22+ conventions requiring annotation processor paths instead of relying on annotation processors present in dependencies.
Closes gh-1121
This commit concludes the support for the "GraphQL over HTTP" spec, with
both clients and servers complying with the expected behavior for the
"application/graphql-response+json" response media type.
Closes gh-1117
This commit renames and changes the behavior of the configuration option
on `GraphQlHttpHandler` implementations. The
`setHttpOkOnValidationErrors` option is `false` by default and is
introduced as a deprecated method right away. Our goal here is to fade
out this option as soon as possible the traditional behavior for
"application/graphql-response+json" media types.
See gh-1117
This commit adapts the GraphQlClient HTTP transports (async and sync) to
accept 4xx responses if the response content type is
"application/graphql-response+json".
This allows the client to support the "GraphQL over HTTP" specification.
This commit adds a new test suite to check compatibility against this
spec.
See gh-1117
This should have been removed when we upgraded to
"io.spring.develocity.conventions:0.0.22".
I suspect this is the reason we are not getting build scan URLs in
GitHub action runs anymore.
Prior to this commit, the `ExecutionGraphQlService` would throw
`GrahphQLException` instances if errors happen early in the process, for
example in some cases of document parsing/validation.
Such exception would be thrown directly and not reflected in the GraphQL
response if those are `GraphQLError`.
This commit ensures that a fallback GraphQL response is created in this
case and that it contains the relevant `GraphQLError` information.
Fixes gh-1118
Prior to this commit, the `GraphQlHttpHandler` implementations for MVC
and WebFlux would support the HTTP transport protocol for servers.
They would align with the well-known GraphQL behavior, using HTTP as a
transport and always using HTTP 200 OK as response status.
The new GraphQL over HTTP specification changes that, and requires
servers to respond with HTTP 4xx/5xx statuses when an error occurs
before the GraphQL request execution: for example, if the JSON document
cannot be parsed, or the GraphQL document is invalid.
This commit introduces a new "standard mode" option on HTTP transports
to follow this new requirement. Because this is a breaking change for
GraphQL clients, this mode is opt-in only for now.
See gh-1117
This commit upgrades to Spring Boot 3.4.x, Spring Framework 6.2.x, and
third party dependency versions used by the project.
Closes gh-1108
Signed-off-by: Stéphane Nicoll <stephane.nicoll@broadcom.com>
We now flatten argument maps to ensure keys in the resulting
parameter map are fully-qualified property paths.
Previously, we built a parameter map containing nested maps
leading to invalid queries.
Closes gh-1085
