Skip to content

fix unwrapGenericType to properly find generic type in arguments Map #361

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

Conversation

jdorleans
Copy link
Contributor

@jdorleans jdorleans commented Jan 31, 2020

Problem

This PR fixes GenericType$RelativeTo.unwrapGenericType method adding the ability to correctly find generic types for a multi-level hierarchy class abstraction. Currently, the following exception occurs in case object is mapped with such case:

Exception in thread "main" java.lang.IllegalStateException: No type variable found for: com.mydomain.MyAbstractClass:T extends com.mydomain.MyTClass<?, ?>
	at com.coxautodev.graphql.tools.GenericType$RelativeTo.unwrapGenericType(GenericType.kt:126)
	at com.coxautodev.graphql.tools.GenericType$RelativeTo.unwrapGenericType(GenericType.kt:100)
	at com.coxautodev.graphql.tools.TypeClassMatcher.match(TypeClassMatcher.kt:34)
	at com.coxautodev.graphql.tools.TypeClassMatcher.match$default(TypeClassMatcher.kt:32)
	at com.coxautodev.graphql.tools.TypeClassMatcher.match(TypeClassMatcher.kt:80)
	at com.coxautodev.graphql.tools.TypeClassMatcher.match(TypeClassMatcher.kt:28)
	at com.coxautodev.graphql.tools.SchemaClassScanner.scanResolverInfoForPotentialMatches(SchemaClassScanner.kt:268)
	at com.coxautodev.graphql.tools.SchemaClassScanner.scanQueueItemForPotentialMatches(SchemaClassScanner.kt:251)
	at com.coxautodev.graphql.tools.SchemaClassScanner.scanQueue(SchemaClassScanner.kt:103)
	at com.coxautodev.graphql.tools.SchemaClassScanner.scanForClasses(SchemaClassScanner.kt:81)
	at com.coxautodev.graphql.tools.SchemaParserBuilder.scan(SchemaParserBuilder.kt:165)
	at com.coxautodev.graphql.tools.SchemaParserBuilder.build(SchemaParserBuilder.kt:206)

Method

GenericType$RelativeTo.unwrapGenericType(GenericType.kt:126)

The existing logic, line 125, returns proper types in a Map, but fails to find type returning null instead.
TypeUtils.determineTypeArguments(getRawClass(mostSpecificType), declaringType)[type]

Expected behavior

unwrapGenericType should be capable of finding generic types independently of number of class extentions. A > B > C

A<T> : B<T>
B<T> : C<T>
C<T>

Solution

Filtering the map by matching type names instead of trying to get by type equality solves the problem.

@jdorleans jdorleans requested a review from oliemansm January 31, 2020 05:45
Copy link
Member

@vojtapol vojtapol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a test that would fail without this fix.

@jdorleans jdorleans force-pushed the fix-unwrap-multi-generic-types branch from 36a3756 to 60123dc Compare February 14, 2020 06:12
@jdorleans
Copy link
Contributor Author

@vojtapol tests added, let me know if they look good. Here's another exception for that particular test in case fix is not in place:

java.lang.IllegalStateException: No type variable found for: graphql.kickstart.tools.place.Place:R extends graphql.kickstart.tools.place.Review<?>

	at graphql.kickstart.tools.GenericType$RelativeTo.unwrapGenericType(GenericType.kt:126)
	at graphql.kickstart.tools.GenericType$RelativeTo.unwrapGenericType(GenericType.kt:100)
	at graphql.kickstart.tools.TypeClassMatcher.match(TypeClassMatcher.kt:30)
	at graphql.kickstart.tools.TypeClassMatcher.match$default(TypeClassMatcher.kt:28)
	at graphql.kickstart.tools.TypeClassMatcher.match(TypeClassMatcher.kt:76)
	at graphql.kickstart.tools.TypeClassMatcher.match(TypeClassMatcher.kt:24)
	at graphql.kickstart.tools.SchemaClassScanner.scanResolverInfoForPotentialMatches(SchemaClassScanner.kt:257)
	at graphql.kickstart.tools.SchemaClassScanner.scanQueueItemForPotentialMatches(SchemaClassScanner.kt:240)
	at graphql.kickstart.tools.SchemaClassScanner.scanQueue(SchemaClassScanner.kt:92)
	at graphql.kickstart.tools.SchemaClassScanner.scanForClasses(SchemaClassScanner.kt:70)
	at graphql.kickstart.tools.SchemaParserBuilder.scan(SchemaParserBuilder.kt:168)
	at graphql.kickstart.tools.SchemaParserBuilder.build(SchemaParserBuilder.kt:209)
	at graphql.kickstart.tools.place.PlaceTest.shouldHandleGenericsDeepHierarchy(PlaceTest.kt:21)
	...

@jdorleans jdorleans requested review from vojtapol and oliemansm and removed request for oliemansm February 14, 2020 06:20
@jdorleans
Copy link
Contributor Author

@vojtapol @oliemansm pls let me know if you need anything else in order to approve this, my team has a few features depending on this fix and we'd love to ship them. Much appreciated.

@vojtapol
Copy link
Member

@jdorleans This will make it to the next release. Nothing else is needed.

@vojtapol vojtapol force-pushed the fix-unwrap-multi-generic-types branch from 1ad07f9 to e55fd82 Compare February 19, 2020 13:35
Copy link
Member

@vojtapol vojtapol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your contribution. 🎉

@vojtapol vojtapol merged commit 2d1314d into graphql-java-kickstart:master Feb 19, 2020
@oliemansm oliemansm added this to the 6.0.0 milestone Feb 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants