wildfly-extras / wildfly-graphql-feature-pack

5 stars 6 forks source link

Typesafe Client not part of the module? #86

Closed t1 closed 2 years ago

t1 commented 2 years ago

I have an application that uses the SmallRye Typesafe GraphQL Client API that's in this feature pack:

<dependency>
    <groupId>io.smallrye</groupId>
    <artifactId>smallrye-graphql-client-api</artifactId>
    <version>1.4.0</version>
    <scope>provided</scope>
</dependency>

When I try to inject an interface annotated as @GraphQLClientApi, the app won't deploy with org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Api with qualifiers @Default.

When I programmatically call TypesafeGraphQLClientBuilder#newBuilder, it throws Caused by: java.lang.ClassNotFoundException: io.smallrye.graphql.client.typesafe.api.TypesafeGraphQLClientBuilder from [Module "deployment.ROOT.war" from Service Module Loader].

If I add only the API to my app, it throws java.util.ServiceConfigurationError: no io.smallrye.graphql.client.typesafe.api.TypesafeGraphQLClientBuilder in classpath.

It works just fine, if I add compile dependencies on smallrye-graphql-client-api and smallrye-graphql-client-implementation-vertx.

This all looks as if the client module isn't loaded at all. Or did I get something wrong? I have reproducer project, if that helps. BTW the server side works fine, too.

jmartisk commented 2 years ago

My guess is that you don't have

Dependencies: io.smallrye.graphql.client.vertx services

inside META-INF/MANIFEST.MF, as described in https://github.com/wildfly-extras/wildfly-graphql-feature-pack/wiki/GraphQL-client-guide#wildfly-modules-related-to-clients ?

I'm not completely sure but you might also need to append

, io.smallrye.graphql.client.common meta-inf

to that line (if yes, please let me know and I'll update the documentation)

Currently this dependency must be added explicitly. For server-side GraphQL usage, there is automatic detection in a deployment processor (which adds the server-side dependencies automatically if it finds a @GraphQLApi), but for client usage we don't have that right now - that would probably call for a separate subsystem :)

t1 commented 2 years ago

Ah... okay... I wasn't aware of that! Now it works... without the dependency on common. I assume you could remove that from the Arquillian test linked in the the wiki, too.

jmartisk commented 2 years ago

I have no idea why a separate dependency on common was needed when writing the test, but now it indeed seems to be working without it, so I'll remove it. Thanks