Spring Cloud Netflix Jersey3DiscoveryClientOptionalArgs may be configured with TlsProperties in EurekaServerAutoConfiguration.java

When SSL for EurekaServer is enabled, I have to define my own jersey3DiscoveryClientOptionalArgs bean. It seems we can do this by default, as DiscoveryClientOptionalArgsConfiguration.java does. DiscoveryClientOptionalArgsConfiguration.java is a part of spring-cloud-netflix-eureka-client, which is one dependency of spring-cloud-netflix-eureka-server. And it has already defined a TlsProperties bean too.

    @Bean
    @ConditionalOnMissingBean(AbstractDiscoveryClientOptionalArgs.class)
    public Jersey3DiscoveryClientOptionalArgs jersey3DiscoveryClientOptionalArgs(TlsProperties tlsProperties)
            throws GeneralSecurityException, IOException {
        Jersey3DiscoveryClientOptionalArgs optionalArgs = new Jersey3DiscoveryClientOptionalArgs();
        if (tlsProperties.isEnabled()) {
            SSLContextFactory factory = new SSLContextFactory(tlsProperties);
            optionalArgs.setSSLContext(factory.createSSLContext());
        }
        return optionalArgs;
    }

Comment From: limo520

The following class trys to do this , but it takes no effect currently. org.springframework.cloud.netflix.eureka.config.DiscoveryClientOptionalArgsConfiguration$DiscoveryClientOptionalArgsTlsConfiguration

It seems that EurekaServerAutoConfiguration is registered after DiscoveryClientOptionalArgsTlsConfiguration, which results in failing to match @ConditionalOnBean(value = AbstractDiscoveryClientOptionalArgs.class, search = SearchStrategy.CURRENT) on DiscoveryClientOptionalArgsTlsConfiguration

Comment From: OlgaMaciaszek

Hi @limo520, thanks for reporting the issue. Please provide a minimal, complete, verifiable example that reproduces the issue.

Comment From: limo520

@OlgaMaciaszek there is an example, https://github.com/limo520/spring-cloud-netflix-issues-4268

Comment From: OlgaMaciaszek

Thanks, @limo520; so if I understand correctly, the scenario is to use TLS with the JerseyClient provided by EurekaServer for intra-peer EurekaServer communication, yes? And the Eureka Server's Jersey3DiscoveryClientOptionalArgs bean is created after DiscoveryClientOptionalArgsConfiguration's setup is processed, therefore it's not taken into account? Have added a draft solution that may address this. @spencergibb does this look ok to you?

Comment From: limo520

@OlgaMaciaszek Yes, you are right. And when I wrote the example, I find another similar issue which can be reproduced by removing eureka.server.my-url in application.yml. It seems becuase of Jersey3ReplicationClient, but I haven't found it out.