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 context object to execute your queries, let the parser know about it so that it can add it to data fetchers as an argument.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: com.coxautodev.graphql.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.