Spring Boot for GemFire - Error creating bean with name 'continuousQueryListenerContainer'

I am using spring boot 2.5.6 and integrating gemfire with it.

Getting exception while deploying the application on PCF as:

Error creating bean with name 'continuousQueryListenerContainer' defined in class path resource [org/springframework/data/gemfire/config/annotation/ContinuousQueryConfiguration.class]: Invocation of init method failed; nested exception is java.lang.IllegalArgumentException: No Pool with name [DEFAULT] was found

dependency which I am using to support gemfire is:

            <groupId>org.springframework.geode</groupId>
            <artifactId>spring-gemfire-starter</artifactId>
            <version>1.2.0.RELEASE</version>
        </dependency>

First, Spring Boot for Apache Geode [and optionally, VMware Tanzu (Pivotal) GemFire] (SBDG) 1.2.x is based on Spring Boot 2.2.x, not 2.5.x! Therefore, this combination is not recommended.

It is SBDG 1.5.6 that is based on Spring Boot 2.5.6, and the latest version in the Spring Boot 2.5.x / SBDG 1.5.x release series is currently, 1.5.7 (with Spring Boot 2.5.7).

Additionally, you should also prefer to be on the latest maintenance/patch release (e.g. 1.2.13.RELEASE; the last patch release in the 1.2 release series) for any major.minor version (e.g. 1.2).

Presumably, you are still on SBDG 1.2, even though it is now EOL, because you have a GemFire 9.8 cluster (?), on which SBDG 1.2 is based. Or, in your case, presumably the version of the PCC cluster in PCF is based on GemFire 9.8??

Finally, you can review all of this information in the SBDG Wiki, Version Compatibility Matrix.

As an aside, this problem is not unlike the problem @rupweb had in this question, "spring data geode pool is not resolvable as a Pool in the application context".

However, this problem is also fundamentally different inside a PCC context, particularly when using SBDG. SBDG derives the PCC cluster (Locators/Servers) connection metadata for the client (the SBDG app) from the PCC environment, namely from VCAP application & service environment variables. It then proceeds in configuring the Locators of all Pools defined. The SDG property generally refers to all Pools created, which is simply the "DEFAULT" Pool when setting up the ClientCache to begin with. Of course, the property can be specialized for specific "named" Pools (see here), however, this is not usually necessary.

Anyway, you can go on to see in Spring Data for Apache Geode [and optionally, VMware Tanzu GemFire] (SDG) specifically, in the 2.2.0.RELEASE, on which SBDG 1.2.0.RELEASE is based, that the "DEFAULT" Pool is initialized from the spring.data.gemfire.pool.locators property setup by SBDG when the app is deployed to PCF, connecting to a PCC cluster.

It is GemFire/Geode itself that sets up a "DEFAULT" Pool when a ClientCache instance is created (which SBDG auto-configures by default; see here).

However, this can be disrupted for 2 reasons (possibly others):

1. First, if you explicitly declared the SDG @ClientCacheApplication annotation on your @SpringBootApplication class, or another Spring @Configuration class, then you effectively override the auto-configuration. Don't do this when using SBDG. If you need to customize the ClientCache configuration, use appropriate properties in application.properties.

2. If you explicitly define/declare a Pool (bean) yourself, then GemFire/Geode forgoes the creation of a "DEFAULT" Pool.

Of course, it is hard to say what is going on for sure since you have not shared any snippets of your application configuration.

I know that the auto-configuration for SDG/GemFire/Geode CQ provided by SBDG works correctly given this Integration Test in the SBDG test suite.

NOTE: There is nothing particularly special about the imported STDG ClientServerIntegerationTestsConfiguration class (here) used by the GemFire client test configuration, other than coordinating the CacheServer port and client Pool port accordingly, given the port is dynamically generated. The client also connects directly to the CacheServer in the test, which is of no consequence.

You can also try 1 of 2 things:

1. First, you can explicitly define a Pool bean with the name "DEFAULT", like so:

@Configuration
@EnablePool(name = "DEFAULT")
class AdditionalGemFireConfiguration {
  // ...
}

By using SDG's @EnablePool annotation, named "DEFAULT", it will make sure a Pool by the name "DEFAULT" exists. And, because SBDG generically refers to all Pools (using the property spring.data.gemfire.pool.locators), then the "DEFAULT" Pool should pick up the configuration coming from SBDG, which again, comes from the VCAP environment inside PCF when using PCC.

2. Alternatively, you can configure a BeanPostProcessor to customize the SDG ContinuousQueryListenerContainer bean auto-configured by SBDG, and set the custom Pool name, accordingly.

Both of these approaches should not be necessary when using the SBDG project and following the conventions described in the docs (also see).

Let's start with this information, and iterate if necessary.