Schema parser options
For advanced use-cases, the schema parser can be tweaked to suit your needs.
Use SchemaParserOptions.newBuilder()
to build an options object to pass to the parser.
Options:
contextClass
: If you use a custom context object to execute your queries, let the parser know about it so that it can add it to data fetchers as an argument.
Make sure to also provide your context instance to the execution input:var executionInput = ExecutionInput.newExecutionInput() .query(query) .variables(variables) .graphQLContext(Map.of(CustomContext.class, context));
genericWrappers
: Allows defining your own generic classes that should be unwrapped when matching Java types to GraphQL types. You must supply the class and the index (zero-indexed) of the wrapped generic type. For example: If you want to unwrap type argumentT
ofFuture<T>
, you must passFuture.class
and0
.useDefaultGenericWrappers
: Defaults totrue
. Tells the parser whether or not to add it’s own list of well-known generic wrappers, such asFuture
andCompletableFuture
.allowUnimplementedResolvers
: Defaults tofalse
. Allows a schema to be created even if not all GraphQL fields have resolvers. Intended only for development, it will log a warning to remind you to turn it off for production. Any unimplemented resolvers will throw errors when queried.missingResolverDataFetcher
: Allows you to provide custom behavior for missing GraphQL fields.inputArgumentOptionalDetectOmission
: Defaults tofalse
. By default, the parser will treat omitted or null method input arguments asOptional.empty
in resolvers. If you prefer, you can disable this behavior.objectMapperConfigurer
/objectMapperProvider
: Exposes the JacksonObjectMapper
that handles marshalling arguments in method resolvers. Every method resolver gets its own mapper, and the configurer can configure it differently based on the GraphQL field definition.preferGraphQLResolver
: In cases where you have a Resolver class and legacy class that conflict on type arguments, use the Resolver class instead of throwing an error. Specifically this situation can occur when you have a graphql schema typeFoo
with abars
property and classes:// legacy class you can't change class Foo { Set<Bar> getBars() { //...returns set of bars... } } // nice resolver that does what you want class FooResolver implements GraphQLResolver<Foo> { Set<BarDTO> getBars() { // ...converts Bar objects to BarDTO objects and returns set... } }
You will now have the code find two different return types for getBars() and application will not start with the error
Caused by: graphql.kickstart.tools.SchemaClassScannerError: Two different classes used for type
If this property is true it will ignore the legacy version.addProxyHandler
: If your runtime resolver classes are auto-generated proxies of some kind you can provide a handler to help the parser find the real resolvers behind them. Four proxy handlers are provided by default for these libraries:- Javassist
- Guice
- Spring AOP
- Weld
introspectionEnabled
: Defaults totrue
. When set tofalse
this option will disable schema introspection viaNO_INTROSPECTION_FIELD_VISIBILITY
. See Field Visibility.fieldVisibility
: Provide a graphql field visibility implementation. This option overridesintrospectionEnabled
when used. See Field Visibility.coroutineContext
/coroutineContextProvider
: Provide a kotlin coroutine context to be used with suspend functions of resolvers.typeDefinitionFactory
: See Type Definition Factory.includeUnusedTypes
: Defaults tofalse
. By default, the parser will ignore unused type definitions in the schema. Enable this option to include them regardless.