FeignClient gets created too early for contract tests

[akutschera]

A while ago I created a bug in Spring Cloud Contract (spring-cloud/spring-cloud-contract#1303)
After some more debugging it looks like the FeignRegistrar registers the feign client before the StubRunner is created, therefore the random port of the stub runner is not set for the feign client (the property that the stubrunner sets is "stubrunner.runningstubs.test-webapp.port", but it sets it too late).
In my example I would expect the test class annotations to be evaluated before the production annotations are.

See the Spring Cloud Contract issue for a sample demonstrating the unexpected behaviour.

[spencergibb]

Feign Clients have timing issues. You can not use them in constructors or post construct. I'm not sure there's anything we can do

[akutschera]

I don't understand your answer. I am autowiring a FeignClient in my test class. That FeignClient has an a url property that gets evaluated before the test class annotations are fully processed (that's why I cannot connect to the test wiremock).
It's all working fine when I use a static port for this.
It's not working when I want to use a random port set by the test. It would work if I used reflection to set the url of the created feignClient proxy which looks hacky to me.
What are the timing issues you are speaking of?

[lukasz-gryzbon]

I also hit the same problem - twice.

To give a bit of a background, my team runs a number of projects. Each has Cucumber component tests that use Feign clients. So basically, we inject Feign clients into the compoent tests to call the service being tested. The services itself uses Feign clients to call other services, which in case of component tests, are Wiremock server(s) span up by the tests themselves.

The problems we have encountered that I feel are related to what was reported here:

1. Because the Feign clients are created so early in the process of spinning up the service (Spring Boot context), when we try to use a random port like this @SpringBootTest(webEnvironment = RANDOM_PORT) and inject the ${server.port} to the properties file as part of the URL proeperty used for @FeignClient(url = "${url}"), the server.port value is not available at the time of creating the Feign client, so we can't use it. We had to fall back to a static port and make sure each project uses a different one so there is not port conflict when building multiple projects on a single machine.
2. We are considering a team wide implementation of Spring Cloud Contract, but we hit the same problem as reported by @akutschera. Spring Cloud Contract use @AutoConfigureStubRunner to load the Wiremock mappings. Part of this process is spinning up the atual Wiremock server on a random port (static port can't be practically used since it marks the Spring context as Dirty after each test which means a new one is created for every test - too slow and too memory consuming). Using a random port requires injecting it to the Feign client, but again, that value becomes available later on in the process, after the Feign clients are created. The Spring Cloud Contract devs say they can't do anything about it spring-cloud/spring-cloud-contract#1303. All the workarounds seem too dirty to implement them. So this problem effectively prevents us from rolling out Spring Cloud Contract.

So my question is - is there a reason why Feign clients are created/bound so early and would it be possible to change the order so they are created after all (or at least some) of the ports have been opened and their numbers are available?

Thanks

[lukasz-gryzbon]

FYI, spring-cloud/spring-cloud-openfeign#455 seems to have fixed problem 2.

[OlgaMaciaszek]

Yes, that fixes the issue. Will backport it to Hoxton as well.