Support placeholders in @FeignClient definitions

[CanD42]

The com.netflix.loadbalancer.LoadBalancerContext takes the original protocol from the @FeignClient definition so if you want to use https you can specify that with (as discussed in #337)

@FeignClient("https://users")

It would be very helpful to support placeholder here so that you can have different schemes in various landscapes:

@FeignClient("${feign.url.scheme}://users")

[beku8]

This feature would be nice, not just to resolve scheme, but for use cases like plug local app to cloud dev environment with prefixes etc.

[CanD42]

Any change to get this into the next release? Thanks

[czolek]

I have stumbled upon this issue myself and thought it would be very helpful to have this resolved. That's why I have implemented the fix (I call it a fix as it is clearly an omission and I categorise it as a bug).
I will submit a pull request in a day or two when I learn how the process works as I have never done so before.
I'll keep you posted.

[dsyer]

I believe you can set <service>.ribbon.IsSecure (or omit <service> for all). Feign hasn't yet been spruced up to support the new ServerIntrospector abstraction (commit aa86267), but it probably should be. So I don't think placeholders is necessarily the way to solve this problem (however handy they would be).

[beku8]

@dsyer I would like to use this feature not to support ssl, but to add prefixes to the services. E.g I would set -Dfoo.servicePrefix=dev_ & feign would connect to dev_foo instead of foo etc.

[dsyer]

I don't think that's a great use case either. The whole point of service discovery is so you don't have to do this kind of thing.

[czolek]

I agree with Dave that placeholders have little use in service discovery. However they are quite useful when using url attribute without service discovery enabled. Also I found it troublesome not to be able to use placeholders in @EnableFeignClients basePackages attribute.
The use-case is that we are developing our own starter project which enables feign clients and by default registers some clients, interceptors etc. Users, of course, can provide their own clients and the idea is to provide an easy to use lib where clients location is specified via a property without the need to provide any additional configuration class. By default we scan at root level /**, but someone may wish to limit scan scope.
I won't argue that the whole idea is vital but it is just nice to have such an option.

[kflorence]

👍 only because this seems like expected behavior and it would be beneficial to pull values from a config -- otherwise, be cautious about disrupting behavior between environments.