Spring Cloud Openfeign Programmatic custom context inside FeignContext

I can do @FeignClient(contextId = "fooClient", name = "stores", configuration = FooConfiguration.class). But if I create the clients manually via FeignClientBuilder (uses ApplicationContext) then I can't see a way to override stuff from FeignClientsConfiguration like an encoder.

I see that there is a FeignContext class, and the concept of NamedContextFactory but there is no way to use it, as I don't have access to the getContext method to register my stuff, nor to implement my own FeignClientSpecification. Since it's there already, I don't think it's a feature request.

My concrete use case is that I have several vendor integrations at the same time, and each vendor has several feign clients with different credentials. One vendor has a custom encoder, and each has a custom decoder to throw custom exceptions. I create each client at runtime by using a FeignClientBuilder. It would've been a little cleaner if I extracted these customizations into FeignClientSpecification for each vendor rather than having them in code.

Comment From: OlgaMaciaszek

HEllo, @Sam-Kruglov , could you please specify with a code example what exactly you would like to do in your use-case and what methods would be helpful so that we can consider whether we should make them available?

Comment From: Sam-Kruglov

Basically I want to provide my own FeignClientSpecification implementation but currently it’s not possible. I’ll provide an example later, on a trip

Comment From: spring-cloud-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: Sam-Kruglov

First, I define this:

public class CustomFeignConfig {

    @Bean
    public XmlMapper xmlMapper() {
        return XmlMapper.builder()
                .findAndAddModules()
                .propertyNamingStrategy(UPPER_CAMEL_CASE)
                .visibility(FIELD, ANY)
                .visibility(GETTER, NONE)
                .visibility(IS_GETTER, NONE)
                .build();
    }

    @Bean
    public ErrorDecoder errorDecoder(XmlMapper mapper) {
        return new CustomErrorDecoder(mapper);
    }

    @Bean
    public BeanPostProcessor delegateEncoder(XmlMapper mapper){
        return new BeanPostProcessor() {
            @Override
            public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
                if (bean instanceof Encoder) {
                    return new XmlDelegateEncoder(mapper, (Encoder) bean);
                }
                return bean;
            }
        };
    }
}

Then elsewhere I define it as a bean:

@Bean
public FeignClientSpecification customSpec() {
    //FeignClientSpecification is package-private
    //second argument is Class<?>[] but would be easier if could scan package classes
    return new FeignClientSpecification("custom-context", CustomFeignConfig.class);
}

And finally, when I create the feign client it will find those beans:

feignClientBuilder.forType(...).contextId("custom-context").*(...).build();

The beans I defined in the first section only affect this particular feign client because it creates new application context under name "custom-context". So, my Spring MVC controller will keep using its own ObjectMapper (instead of my XmlMapper) and also other feign clients can use their own error decoders as error format is unique to each system.

The example above can be done if FeignClientSpecification becomes public instead of package-private. Those are already autowired into FeignAutoConfiguration but cannot be created for this reason.

@FeignClient annotation contains some useful fields but my IDE couldn't find any usages of those, so can't see how it works there. There is FeignClient#configuration where user can specify a class with beans in it but since I couldn't find how it's used programmatically, I couldn't mimic this for using with feign builder.

Comment From: Sam-Kruglov

Silly me, wrote all this text when PR takes 2 words

Comment From: OlgaMaciaszek

@Sam-Kruglov Thanks for submitting it. It's good you've written all it, cause now we know why it might make sense to change the access. Will take a closer look at this next week.

Comment From: OlgaMaciaszek

Let's make it public.