Unable to determine data class for resolver '...' from generic interface! This is most likely a bug with graphql-java-tools. #349

Activity

1. mxmlnglt commented on Jan 2, 2020

   

   mxmlnglt

   on Jan 2, 2020

   Last edited by mxmlnglt

   Author

   More actions

   My only workaround for now is to move the implements GraphQLResolver<T> to the actual resolver:

   @Component
   public abstract class MotherResolver<T extends Mother> implements GraphQLResolver<T> { // can be removed from here, it's totally useless...
       // Resolving methods for Mother's fields
   }
   

   @Component
   public class ChildResolver extends MotherResolver<Child> implements GraphQLResolver<Child> { // totally needed here
       // Resolving methods for Child's fields
   }
   

   Edit: fixed from GraphQLResolver<T> to GraphQLResolver<Child> in the ChildResolver, thanks @Geeseen
2. geesen commented on Feb 3, 2020

   

   geesen

   on Feb 3, 2020

   More actions

   @Component
   public class ChildResolver extends MotherResolver<Child> implements GraphQLResolver<T> { // totally needed here
       // Resolving methods for Child's fields
   }
   

   Did you mean:

   @Component public class ChildResolver extends MotherResolver<Child> implements GraphQLResolver<Child> { ...}

   ?
3. mxmlnglt commented on Feb 3, 2020

   

   mxmlnglt

   on Feb 3, 2020

   Author

   More actions

   @Component
   public class ChildResolver extends MotherResolver<Child> implements GraphQLResolver<T> { // totally needed here
       // Resolving methods for Child's fields
   }
   

   Did you mean:

   @Component public class ChildResolver extends MotherResolver<Child> implements GraphQLResolver<Child> { ...}

   ?

   Oh yeah, right, I missed this before posting (probably just a copy-paste problem).
4. geesen commented on Feb 4, 2020

   

   geesen

   on Feb 4, 2020

   More actions

   Ok, as suspected ;-)
   Unfortunately, it doesn't work for me if I move the GraphQLResolver from the superclass down to the actual class, when there is also a generic typed method in the super class.

   For example, if I have the following:

   @Component
   public abstract class MotherResolver<T extends Mother> { 
   
        public T getNext(){
           return ...
        }        
   }

   This is not working (No type variable found for T)

   @Component
   public class ChildResolver extends MotherResolver<Child> implements GraphQLResolver<Child> { 
       
   }

   But, if I explicitly overwrite the method and call its super method, it is working:

   @Component
   public class ChildResolver extends MotherResolver<Child> implements GraphQLResolver<Child> { 
     
       public Child  getNext(){
           return super.getNext();
        }        
   }

   Of course, this is only an interim solution, because the child resolvers are then inflated unnecessarily and the advantage of Java inheritance does not pay off here - quite apart from the non-existing DRY principle.

   Normally, you should be able to define methods centrally in the MotherResolver, which then also apply to all ChildResolvers, without having to touch the ChildResolver individually.
5. mxmlnglt commented on Feb 6, 2020

   

   mxmlnglt

   on Feb 6, 2020

   Author

   More actions

   Normally, you should be able to define methods centrally in the MotherResolver, which then also apply to all ChildResolvers, without having to touch the ChildResolver individually.

   Yes, exactly. That's what I do.
6. geesen commented on Feb 6, 2020

   

   geesen

   on Feb 6, 2020

   More actions

   Normally, you should be able to define methods centrally in the MotherResolver, which then also apply to all ChildResolvers, without having to touch the ChildResolver individually.

   Yes, exactly. That's what I do.

   And it is working for you?
7. guodage commented on Mar 11, 2020

   

   guodage

   on Mar 11, 2020

   Last edited by guodage

   More actions

   graphql-java-tools could not parse the <T> in
   MotherResolver<T extends SomeObj> implements GraphQLResolver<T>,
   we need do this.
8. matsmad commented on Nov 13, 2020

   

   matsmad

   on Nov 13, 2020

   Last edited by matsmad

   More actions

   Any updates on this?

   I'm building a sample project and trying to build a common Resolver to resolve properties of classes at one place
   For example

   public interface MyInterface {
       String getSome();
   }
   
   

   public class ClassA implementes  MyInterface {
       String getSome();
   // further props
   }
   

   public classB implements MyInterface {
       String getSome();
   // further props
   }
   
   
   

   public class MyAweseomeResolver<T extends MyInterface> implements GraphQLResolver<T> {
       public String getSomeString(final T concrete) {
            return concrete.getSome().toUpperCase()
       }
   }
   

   Background:
   I don't want to implement a resolver for each class which are at least doing the same.
   I just want to have one resolver which applies to all classes implementing one interface.
9. mxmlnglt commented on Dec 3, 2020

   

   mxmlnglt

   on Dec 3, 2020

   Author

   More actions

   @matsmad AFAIK there has been no intervention from someone of the team here; so you'll probably have to apply my workaround: #349 (comment)
10. oryan-block commented on Oct 3, 2026

    

    oryan-block

    on Oct 3, 2026

    Collaborator

    More actions

    The original case, an abstract MotherResolver<T extends Mother> implements GraphQLResolver<T> extended by ChildResolver extends MotherResolver<Child>, has worked since 5.7.0 thanks to #332. It's covered by GenericResolverTest.

    To share one resolver across all implementors of an interface (@matsmad's case), write a GraphQLResolver<MyInterface>. That's supported since #820 and ships in 14.0.4. A generic resolver instantiated directly (e.g. new MyResolver<ClassA>()) can't work, because the type argument is erased at runtime. Subclass it with a concrete type instead.
11. oryan-block

    closed this as completedon Oct 3, 2026