Unable to inject rest client defined in a different module in a multi module project

[roguexz]

Describe the bug
I have a multi-module project setup. I am able to use @restclient based injections for interfaces that are part of the same module (and registered with the @RegisterRestClient annotation).

E.g.,

my-project
    |
    |- module-1
        src/main/java/mypackage
            RestAPIInterface.java
        src/test/java/
            @Inject @RestClient RestAPIInterface -- works
    |
    |- module-2
        src/main/java/myOtherPackage
            SomeBean.java
                @Inject @RestClient RestAPIInterface -- does not work

Do I need to enable any specific features / switches in order to get this working?

Expected behavior
I should be able to inject Rest clients defined in other modules within the same project.

Actual behavior
Test case fails stating that there is no client definition

To Reproduce
Steps to reproduce the behavior:

1. Clone https://github.com/roguexz/quarkus-sample
2. Execute ./gradlew clean test
3. Observe that the test fails for the consumer module.

Configuration

------------------------------------------------------------
Gradle 6.0.1
------------------------------------------------------------

Build time:   2019-11-18 20:25:01 UTC
Revision:     fad121066a68c4701acd362daf4287a7c309a0f5

Kotlin:       1.3.50
Groovy:       2.5.8
Ant:          Apache Ant(TM) version 1.10.7 compiled on September 1 2019
JVM:          1.8.0_231 (Oracle Corporation 25.231-b11)
OS:           Mac OS X 10.14.6 x86_64

Screenshots
(If applicable, add screenshots to help explain your problem.)

Environment (please complete the following information):

• Quarkus version or git rev: 1.2.1.Final

[gsmet]

@mkouba @kenfinnigan any chance one of you could have a look at that one?

[gsmet]

It's failing with 1.3.0.Alpha2 too btw.

[roguexz]

I updated the test repository. The problem does not show up if you have only two modules. But if you have more than two, that is when this problem comes up.

[mkouba]

I can take a look...

[roguexz]

I think I might have found at least one problem. In the sample repository, the application.properties file is not being picked up from the the incoming project dependencies. I am trying out some fixes in my local that might help. Here is what I am think about, and would like to know if it has already been incorporated or something that might be useful.

1. Add support for including additional property files in TestHTTPConfigSourceProvider.java. This could be on the same lines as how the DEPLOYMENT_CP is passed along, i.e., space separate system property.
2. In QuarkusTestConfig, concatenate any available application.properties files that are part of the incoming dependencies (which happen to be projects) and then export the system property.

What do you think?

[kenfinnigan]

What would be interesting is trying the project with Maven to determine whether it's a build type issue or a code issue

[mkouba]

Yes, so the root cause is java.lang.IllegalArgumentException: Unable to determine the proper baseUrl/baseUri. Consider registering using @RegisterRestClient(baseUri="someuri"), @RegisterRestClient(configKey="orkey"), or by adding 'anotherEndPoint/mp-rest/url' or 'anotherEndPoint/mp-rest/uri' to your Quarkus configuration

In the sample repository, the application.properties file is not being picked up from the the incoming project dependencies.

I don't think this is supported at the moment. @stuartwdouglas @dmlloyd Am I right?

[roguexz]

I think I have a fix. Give me some time, and I will share it. If it makes sense, we can include it.

[roguexz]

I believe I might have found the problem.

For the missing configurations, I am working around it by providing a custom ConfigSourceProvider. So, that is no longer an issue.

For the original issue, I realized that all along, I was passing the required dependencies for the test cases via the testImplementation configuration. But the AppModelGradleResolver was expecting the dependencies to be on the "compileClassPath" of the project.

I have updated the sample project to reflect the same.

I see there are some changes for this class in the main line, but I can confirm that the updated sample is still failing with 1.3.0.Alpha2.

When I updated the code locally to use the test runtime classpath instead, I see the builds going through smoothly.

How do you folks want to take this forward?

[aloubyansky]

I'm seeing

Caused by: java.lang.RuntimeException: RESTEASY003875: Unable to find a constructor that takes a String param or a valueOf() or fromString() method for javax.ws.rs.QueryParam("before") on public java.lang.String org.acme.SimpleService.doSomething(java.time.OffsetDateTime) for basetype: java.time.OffsetDateTime
	at org.jboss.resteasy.core.StringParameterInjector.initialize(StringParameterInjector.java:457)
	at org.jboss.resteasy.core.StringParameterInjector.<init>(StringParameterInjector.java:400)
	at org.jboss.resteasy.core.QueryParamInjector.<init>(QueryParamInjector.java:31)
	at org.jboss.resteasy.core.InjectorFactoryImpl.createParameterExtractor0(InjectorFactoryImpl.java:100)
	at org.jboss.resteasy.core.InjectorFactoryImpl.lambda$createParameterExtractor$0(InjectorFactoryImpl.java:91)
	at org.jboss.resteasy.core.InjectorFactoryImpl$OptionalInjections.lambda$wrap$8(InjectorFactoryImpl.java:301)
	at java.util.Optional.orElseGet(Optional.java:267)
	at org.jboss.resteasy.core.InjectorFactoryImpl$OptionalInjections.wrap(InjectorFactoryImpl.java:301)
	at org.jboss.resteasy.core.InjectorFactoryImpl.createParameterExtractor(InjectorFactoryImpl.java:91)
	at org.jboss.resteasy.core.MethodInjectorImpl.<init>(MethodInjectorImpl.java:45)
	at org.jboss.resteasy.core.InjectorFactoryImpl.createMethodInjector(InjectorFactoryImpl.java:85)
	at org.jboss.resteasy.core.ResourceMethodInvoker.<init>(ResourceMethodInvoker.java:133)
	at org.jboss.resteasy.core.ResourceMethodRegistry.processMethod(ResourceMethodRegistry.java:382)
	at org.jboss.resteasy.core.ResourceMethodRegistry.register(ResourceMethodRegistry.java:309)
	at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:260)
	at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:227)
	at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:208)
	at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:192)
	at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:175)
	at org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:87)
	at org.jboss.resteasy.core.ResteasyDeploymentImpl.registerResources(ResteasyDeploymentImpl.java:513)
	at org.jboss.resteasy.core.ResteasyDeploymentImpl.registration(ResteasyDeploymentImpl.java:470)
	at org.jboss.resteasy.core.ResteasyDeploymentImpl.startInternal(ResteasyDeploymentImpl.java:160)
	at org.jboss.resteasy.core.ResteasyDeploymentImpl.start(ResteasyDeploymentImpl.java:117)
	at io.quarkus.resteasy.runtime.standalone.ResteasyStandaloneRecorder.staticInit(ResteasyStandaloneRecorder.java:86)
	at io.quarkus.deployment.steps.ResteasyStandaloneBuildStep$staticInit24.deploy_0(ResteasyStandaloneBuildStep$staticInit24.zig:904)
	at io.quarkus.deployment.steps.ResteasyStandaloneBuildStep$staticInit24.deploy(ResteasyStandaloneBuildStep$staticInit24.zig:923)
	at io.quarkus.runner.ApplicationImpl.<clinit>(ApplicationImpl.zig:397)

Is that supposed to work?

[aloubyansky]

The above was the result of running the reproducer against #8707, which I think should fix the key issue here.

[aloubyansky]

I believe the main issue should be fixed in the 1.5.0.Final. The reproducer is also suffering from #9017 which is going to be fixed by #9774