-1

SSLConfiguration inherits ClientGemFirePropertiesConfigurer from EmbeddedServiceConfigurationSupport class. When I EnableSSL which loads SSLConfiguration, the runtime fails with error - Bean ClientGemfirePropertiesConfigurer already defined.

Library spring-data-gemfire 2.2.0.RELEASE

Can you please advice how to resolve this?

I dont want to enable bean override at global level, we have other integrations that I don't want to impact for this issue.

1 Answers1

1

First, Spring Data for VMware Tanzu GemFire (SDG) 2.2 is already EOL. Ideally, you should use SDG 2.5 (i.e. 2.5.4, the current and latest release).

Also, since SDG 2.4, there are no longer any SDG bits based on GemFire since GemFire is no longer being released as a standalone product by VMware after GemFire 9.10. SDG 2.3 was the last release with official bits for both Apache Geode and VMware Tanzu GemFire. SDG 2.3 was based on Apache Geode 1.12 and (based on) GemFire 9.10, where GemFire 9.10 is based on Geode 1.12 (itself). Although VMware Tanzu GemFire is based on Apache Geode in general, as of SDG 2.4, SDG is based on Geode 1.13 for which there are no GemFire releases, and so bits for GemFire were dropped.

Finally, SDG 2.3 is nearing EOL as Spring Boot has already stopped releasing and supporting Spring Boot 2.3 OSS, and commercial support is ending in 2022 (see here).

Regarding your specific problem (involving bean definition overriding), I suspect you have conflicting and incorrect configuration in your application somewhere.

I wrote a test demonstrating that SDG works correctly in this case.

This test configures both Security (Auth) and SSL, since this is a common use case. Both Security (Auth) and SSL configuration involves configuring GemFire properties upfront (i.e. before GemFire starts) and therefore, both associated configuration classes (i.e. SslConfiguration and GeodeIntegratedSecurityConfiguration) extend SDG's abstract EmbeddedServiceConfigurationSupport class.

Subsequently, this means both SDG Security and SSL enabling annotations will add ClientGemFirePropertiesConfigurer beans (1 for Auth/Security and 1 for SSL to the Spring ApplicationContext).

The result, SDG functions correctly and the test passes, as expected. Additionally, the configuration is correct and this is the case even when the Spring container's allowBeanDefinitionOverriding property is disabled, as seen here, here and then here.

NOTE: The core Spring Framework allows bean definition overriding by default. Only Spring Boot disables the core Spring container bean definition overriding by default.

Therefore, in my test, I explicitly disable bean definition overriding and verify that the Spring container bean definition overriding is, in fact, disabled.

Again, the test passes because all the ClientGemFirePropertiesConfigurer beans created by the SDG framework are in fact uniquely named, as you can see if you trace down to here.

1 of the more common but less apparent ways in which this might be a problem is if you have duplicate (possibly conflicting) configuration, thereby making it non-obvious and ambiguous which configuration should take effect.

I can reproduce your error when I do just that, e.g. by specifying the @EnableSsl annotation on more than 1 Spring @Configuration class, that is IncorrectTestConfiguration in addition to TestConfiguration. You can see this behavior if you enable the incorrect-test-configuration profile.

Of course, you should not specify SSL configuration more than once in your GemFire/Geode arrangement (and Spring [Boot] application).

Did you perhaps forget to distinguish which configurations should take effect by adding @Profile declarations, or maybe mistakenly enable more than 1 profile with conflicting configuration?

I only tested with SDG 2.5 bits (and above). If this was a problem for 2.2, then since SDG 2.2 is already EOL, I would suggest you upgrade as we will not be patching the SD[G] 2.2 release line any further.

If you are convinced this is still a bug in the latest release even, then please share a simple code sample that reproduces the problem and file an GitHub Issue ticket here.

John Blum
  • 7,381
  • 1
  • 20
  • 30
  • I may have thought of another scenario where this is still a problem... component based SSL configuration (e.g. client/server vs. WAN). Therefore, a user might want to declare the `@EnableSsl` annotation multiple times to configure individual network components (e.g. again, client/server vs. WAN) of GemFire/Geode separately. I will investigate further and get back to you when I know more. – John Blum Sep 17 '21 at 17:54
  • After further investigation, even component-based SSL configuration uses the same general SSL settings (i.e. ciphers, keystore/truststore, protocols, etc). However, the keystore/truststore can store certs per component and be referenced in GemFire/Geode properties using component certificate aliases. This ultimately means you still only want to declare 1 SDG `@EnableSsl` annotation and **NOT** multiple per Geode component. Instead you would store all certs in the same keystore/truststore and distinguish by component certificate aliases. My answer above stands correctly. – John Blum Sep 17 '21 at 18:51