Is your feature request related to a problem? Please describe.

https://github.com/spring-cloud/spring-cloud-openfeign/blob/0828fff93f5c17d2416a2a187c2f34cd35198a3a/spring-cloud-openfeign-core/src/main/java/org/springframework/cloud/openfeign/support/SpringDecoder.java#L52-L59

This simple constructor requiring only messageConverters has been deprecated since #543. I don't have specific customizers, so SpringDecoder(messageConverters) still works fine with me. There must be some reason on 6218eeb even if it has no explanation in the commit message body, so I'd like to hear it. If not, please bring it back.

Describe the solution you'd like

Remove @Depcrecated annotation.

Describe alternatives you've considered

https://github.com/spring-cloud/spring-cloud-openfeign/blob/0828fff93f5c17d2416a2a187c2f34cd35198a3a/spring-cloud-openfeign-core/src/main/java/org/springframework/cloud/openfeign/support/EmptyObjectProvider.java#L27

Open EmptyObjectProvider public.

Additional context

  • https://github.com/spring-cloud/spring-cloud-openfeign/pull/543#discussion_r865728261
  • 6218eeb

Comment From: al-anna

I support the question / request At the moment I can only see three options for a workaround: - either use a deprecated constructor (and use of deprecated methods is highlighted as a potential vulnerability by some of the static code scanning tools) - put a copy of EmptyObjectProvider into our own project and make use of it, which is also problematic as it is overrides @NonNullApi methods with a {return null;} implementation which is also an issue for code scanning tools - invent your own version of EmptyObjectProvider which would pass through all static code checks but that's a waste of effort as in the end we don't want any customizers..

Comment From: georgeanderson

I have just come across this problem. Removing @Deprecated annotation seems the most sensible approach here. I can submit a merge request for that, but giving this issue hasn't been triaged since March makes me wonder if the change wouldn't be equally "ignored".

Comment From: al-anna

One option we found is let Spring autowire the customizers by providing them in the Decoder constructing method, like

  @Bean(name = "feignDecoder")
  public Decoder myFeignDecoder(
      final @Qualifier("objectMapper") ObjectMapper objectMapper,
      final ObjectProvider<HttpMessageConverterCustomizer> customizers) {                                   // this
    final MappingJackson2HttpMessageConverter jacksonConverter =
        new MappingJackson2HttpMessageConverter(objectMapper);
    final ObjectFactory<HttpMessageConverters> objectFactory =
        () -> new HttpMessageConverters(jacksonConverter);
    return new ResponseEntityDecoder(new SpringDecoder(objectFactory, customizers));               // and then using those
  }

Unless there's something funny in your classpath Spring will autowire an empty list of customizers and this is what we were looking for in first place. This was a bit of a creative solution to avoid any static code scan tool issues raised.

Comment From: OlgaMaciaszek

Thanks @djkeh. Makes sense. I think it was over-eager clean-up on our side. Will revert it.

Comment From: OlgaMaciaszek

Fixed with 19d0b8188ad3b43af20156aeed86a8d526a66919.