Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeMappingException: Type io.leangen.graphql.spqr.spring.autoconfigure.DefaultGlobalContext is unbounded or missing generic type parameters #29

csueiras opened this issue Mar 16, 2019 · 1 comment


None yet
1 participant
Copy link

commented Mar 16, 2019

Hi I believe I found a bug, whenever the DefaultGlobalContext is injected without the type being specified for the request object a TypeMappingException is raised:

Caused by: io.leangen.graphql.metadata.exceptions.TypeMappingException: Type io.leangen.graphql.spqr.spring.autoconfigure.DefaultGlobalContext is unbounded or missing generic type parameters
	at io.leangen.graphql.util.ClassUtils.completeGenerics( ~[spqr-0.9.9.jar:na]
	at io.leangen.graphql.metadata.strategy.type.DefaultTypeTransformer.transform( ~[spqr-0.9.9.jar:na]
	at io.leangen.graphql.metadata.strategy.query.AnnotatedArgumentBuilder.buildResolverArguments( ~[spqr-0.9.9.jar:na]
	... 65 common frames omitted

Here's an example to reproduce:

public class SpqrBugService {
    @GraphQLQuery(name = "coolPeople")
    public List<String> findCoolPeople(@GraphQLArgument(name = "coolnessFactor") final int factor,
                                       @GraphQLRootContext final DefaultGlobalContext ctx) {

        if (factor > 5) {
            return ImmutableList.of("Me");

        return ImmutableList.of();

A workaround is to do:

@GraphQLRootContext final DefaultGlobalContext<Object> ctx

graphql-spqr version 0.9.9
graphql-spqr-spring-boot-starter 0.0.4


This comment has been minimized.

Copy link
Contributor Author

commented Mar 17, 2019

I thought about this some more, the issue is that if you are in the context of a subscription the DefaultGlobalContext's type would be WebSocketSession but if it's in the context of a query then you would get HttpServletRequest, which is why I am not providing the type (I'm pretty sure I saw an example @kaqqao provided somewhere without the type specified). Maybe a fix for this is to either relax the type checking thats going on or perhaps a bit better is to remove the generic typing from the DefaultGlobalContext and use turn the getNativeRequest into a generic method that will cast to whatever the specialized type should be?

I'll donate a PR for this if this approach sounds good @kaqqao ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.