question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Document classpath* location for looking up GraphQL schemas across modules

See original GitHub issue

Version Spring Boot 2.7.1

Description We created a new itest source set in Gradle and when we run the test using @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT), seems like the autoconfigure GraphQL components are not provisioned.

How to reproduce it This project contains a pretty simple GraphQL controller, with two tests:

  • One inside the test source set, using RestAssured to call the GraphQL endpoint, which works fine (HTTP 200)
  • One inside the itest source set, using RestAssured to call the GraphQL endpoint, which doesn’t work (HTTP 404)

Clues I did some debugging and found that ConditionalOnGraphQlSchema returns true for the test source set, and false for the itest source set, it seems like this line on DefaultGraphQlSchemaCondition cannot find the GraphQL schema, and therefore, Spring Boot doesn’t contribute the Graphql autoconfiguration.

My guess is this issue might be for Spring Boot and not Gradle configuration, as other resources work fine, like liquibase changelogs and application.yml files.

Issue Analytics

  • State:closed
  • Created a year ago
  • Comments:5 (5 by maintainers)

github_iconTop GitHub Comments

1reaction
bclozelcommented, Sep 20, 2022

Thanks Rossen, I’ll add a similar note in the Spring Boot reference docs, I’ll turn this into a documentation issue then.

1reaction
rstoyanchevcommented, Sep 20, 2022

That’s the same problem indeed, just with a different source of the unwanted graphql package that stops the file from being found.

As of https://github.com/spring-projects/spring-graphql/issues/338, we look in different places for schema vs test request vs client request files, which eliminates a very basic reason to shadowing graphql/ under main and test sources that most apps would run into otherwise.

For the rest, using classpath*: by default will find all possible candidates out of the box, including some that may not be intended for inclusion, while classpath: requires an explicit action to decide how to deal with such shadowing. I tend to think the more explicit opt-in option is preferable. I’ve already made an adjustment to the Spring for GraphQL docs to make that easier to spot.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Document classpath* location for looking up GraphQL ...
Forward port of issue #31772 to 3.0.x.
Read more >
Java GraphQL schema dependency across modules
1 Answer 1 ... In your case, there are two different problems that need to be solved: the Spring for GraphQL auto-detection of...
Read more >
Spring for GraphQL Documentation
Use classpath*:graphql/**/ to find schema files across multiple classpath locations, e.g. across multiple modules.
Read more >
Modularizing your GraphQL schema code
To organize your code, you'll want to split up your schema types and the associated resolvers into multiple files.
Read more >
Code Generation - DGS Framework - Netflix Open Source
The DGS Code Generation plugin generates code during your project's build process based on your Domain Graph Service's GraphQL schema file.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found