[[geode-configuration-auto]]
== Auto-configuration
:geode-name: {apache-geode-name}


The following Spring Framework, Spring Data for {geode-name} (SDG) and Spring Session for {geode-name} (SSDG)
annotations are implicitly declared by Spring Boot for {geode-name}'s (SBDG) auto-configuration.

* `@ClientCacheApplication`
* `@EnableGemfireCaching` (alternatively, Spring Framework's `@EnableCaching`)
* `@EnableContinuousQueries`
* `@EnableGemfireFunctions`
* `@EnableGemfireFunctionExecutions`
* `@EnableGemfireRepositories`
* `@EnableLogging`
* `@EnablePdx`
* `@EnableSecurity`
* `@EnableSsl`
* `@EnableGemFireHttpSession`

NOTE: This means that you need not explicitly declare any of these annotations on your `@SpringBootApplication` class,
since they are provided by SBDG already. The only reason you would explicitly declare any of these annotations is to
override Spring Boot's, and in particular, SBDG's auto-configuration. Otherwise, doing so is unnecessary.

TIP: You should read the chapter in Spring Boot's reference documentation on
{spring-boot-docs-html}/#using-boot-auto-configuration[auto-configuration].

TIP: You should review the chapter in Spring Data for {geode-name}'s (SDG) reference documentation
on {spring-data-geode-docs-html}/#bootstrap-annotation-config[annotation-based configuration]. For a quick reference
and overview of annotation-based configuration, see the
{spring-data-geode-docs-html}/#bootstap-annotations-quickstart[annotations quickstart].

TIP: See the corresponding sample link:guides/boot-configuration.html[guide] and {github-samples-url}/boot/configuration[code]
to see Spring Boot auto-configuration for {geode-name} in action.

[[geode-configuration-auto-customizing]]
=== Customizing Auto-configuration

You might ask, "`How do I customize the auto-configuration provided by SBDG if I do not explicitly declare
the annotation?`"

For example, you may want to customize the member's name.  You know that the
{spring-data-geode-javadoc}/org/springframework/data/gemfire/config/annotation/ClientCacheApplication.html[`@ClientCacheApplication`] annotation
provides the {spring-data-geode-javadoc}/org/springframework/data/gemfire/config/annotation/EnableGemFireProperties.html#name--[`name`] attribute
so that you can set the client member's name. However, SBDG has already implicitly declared the `@ClientCacheApplication`
annotation through auto-configuration on your behalf. What do you do?

In this case, SBDG supplies a few additional annotations.

For example, to set the (client or peer) member's name, you can use the `@UseMemberName` annotation:

.Setting the member's name using `@UseMemberName`
====
[source,java]
----
@SpringBootApplication
@UseMemberName("MyMemberName")
class SpringBootApacheGeodeClientCacheApplication {
	//...
}
----
====

Alternatively, you could set the `spring.application.name` or the `spring.data.gemfire.name` property in Spring Boot
`application.properties`:

.Setting the member's name using the `spring.application.name` property
====
[source,txt]
----
# Spring Boot application.properties

spring.application.name = MyMemberName
----
====

.Setting the member's name using the `spring.data.gemfire.cache.name` property
====
[source,txt]
----
# Spring Boot application.properties

spring.data.gemfire.cache.name = MyMemberName
----
====

NOTE: The `spring.data.gemfire.cache.name` property is an alias for the `spring.data.gemfire.name` property. Both
properties do the same thing (set the name of the client or peer member node).

In general, there are three ways to customize configuration, even in the context of SBDG's auto-configuration:

* Using {spring-boot-data-geode-javadoc}/org/springframework/geode/config/annotation/package-summary.html[annotations]
provided by SBDG for common and popular concerns (such as naming client or peer members with the `@UseMemberName`
annotation or enabling durable clients with the `@EnableDurableClient` annotation).

* Using well-known and documented {spring-data-geode-docs-html}/#bootstrap-annotation-config-properties[properties]
(such as `spring.application.name`, or `spring.data.gemfire.name`, or `spring.data.gemfire.cache.name`).

* Using {spring-data-geode-docs-html}/#bootstrap-annotation-config-configurers[configurers]
(such as {spring-data-geode-javadoc}/org/springframework/data/gemfire/config/annotation/ClientCacheConfigurer.html[`ClientCacheConfigurer`]).

TIP: For the complete list of documented properties, see <<geode-configuration-metadata>>.

[[geode-configuration-auto-disabling]]
=== Disabling Auto-configuration

Spring Boot's reference documentation explains how to
{spring-boot-docs-html}/#using-boot-disabling-specific-auto-configuration[disable Spring Boot auto-configuration].

<<geode-auto-configuration-disable>> also explains how to disable SBDG auto-configuration.

In a nutshell, if you want to disable any auto-configuration provided by either Spring Boot or SBDG, declare your intent
in the `@SpringBootApplication` annotation:

.Disabling Specific Auto-configuration Classes
====
[source,java]
----
@SpringBootApplication(
  exclude = { DataSourceAutoConfiguration.class, PdxAutoConfiguration.class }
)
class SpringBootApacheGeodeClientCacheApplication {
	// ...
}
----
====

CAUTION: Make sure you understand what you are doing when you disable auto-configuration.

[[geode-configuration-auto-overriding]]
=== Overriding Auto-configuration

<<geode-autoconfiguration-annotations-overriding>> explains how to override SBDG auto-configuration.

In a nutshell, if you want to override the default auto-configuration provided by SBDG, you must annotate your
`@SpringBootApplication` class with your intent.

For example, suppose you want to configure and bootstrap an {geode-name} `CacheServer` application
(a peer, not a client):

.Overriding the default `ClientCache` _Auto-Configuration_ by configuring & bootstrapping a `CacheServer` application
====
[source,java]
----
@SpringBootApplication
@CacheServerApplication
class SpringBootApacheGeodeCacheServerApplication {
	// ...
}
----
====

You can also explicitly declare the `@ClientCacheApplication` annotation on your `@SpringBootApplication` class:

.Overriding by explicitly declaring `@ClientCacheApplication`
====
[source,java]
----
@SpringBootApplication
@ClientCacheApplication
class SpringBootApacheGeodeClientCacheApplication {
	// ...
}
----
====

You are overriding SBDG's auto-configuration of the `ClientCache` instance. As a result, you have now also implicitly
consented to being responsible for other aspects of the configuration (such as security).

Why does that happen?

It happens because, in certain cases, such as security, certain aspects of security configuration (such as SSL) must be
configured before the cache instance is created. Also, Spring Boot always applies user configuration before
auto-configuration partially to determine what needs to be auto-configured in the first place.

CAUTION: Make sure you understand what you are doing when you override auto-configuration.

[[geode-configuration-auto-replacing]]
=== Replacing Auto-configuration

See the Spring Boot reference documentation on
{spring-boot-docs-html}/#using-boot-replacing-auto-configuration[replacing auto-configuration].

[[geode-configuration-auto-explained]]
=== Understanding Auto-configuration

This section covers the SBDG provided auto-configuration classes that correspond to the SDG annotations in more detail.

To review the complete list of SBDG auto-confiugration classes, see <<geode-auto-configuration-disable-classes>>.

[[geode-configuration-declarative-auto-configuration-clientcacheapplication]]
==== `@ClientCacheApplication`

NOTE: The SBDG {spring-boot-data-geode-javadoc}/org/springframework/geode/boot/autoconfigure/ClientCacheAutoConfiguration.html[`ClientCacheAutoConfiguration`] class
corresponds to the SDG {spring-data-geode-javadoc}/org/springframework/data/gemfire/config/annotation/ClientCacheApplication.html[`@ClientCacheApplication`] annotation.

As explained in <<getting-started>> SBDG starts with the opinion that application developers primarily build {geode-name}
<<geode-clientcache-applications,client applications>> by using Spring Boot.

Technically, this means building Spring Boot applications with an {geode-name} `ClientCache` instance connected to
a dedicated cluster of {geode-name} servers that manage the data as part of a
{apache-geode-docs}/topologies_and_comm/cs_configuration/chapter_overview.html[client/server] topology.

By way of example, this means that you need not explicitly declare and annotate your `@SpringBootApplication` class
with SDG's `@ClientCacheApplication` annotation, as the following example shows:

.Do Not Do This
====
[source,java]
----
@SpringBootApplication
@ClientCacheApplication
class SpringBootApacheGeodeClientCacheApplication {
	// ...
}
----
====

SBDG's provided auto-configuration class is already meta-annotated with SDG's `@ClientCacheApplication` annotation.
Therefore, you need only do:

.Do This
====
[source,java]
----
@SpringBootApplication
class SpringBootApacheGeodeClientCacheApplication {
	// ...
}
----
====

TIP: See SDG's reference documentation for more details on {geode-name}
{spring-data-geode-docs-html}/#bootstrap-annotation-config-geode-applications[cache applications]
and {spring-data-geode-docs-html}/#bootstrap-annotation-config-client-server-applications[client/server applications]
in particular.

[[geode-configuration-declarative-auto-configuration-enablecaching]]
==== `@EnableGemfireCaching`

NOTE: The SBDG {spring-boot-data-geode-javadoc}/org/springframework/geode/boot/autoconfigure/CachingProviderAutoConfiguration.html[`CachingProviderAutoConfiguration`] class
corresponds to the SDG {spring-data-geode-javadoc}/org/springframework/data/gemfire/cache/config/EnableGemfireCaching.html[`@EnableGemfireCaching`] annotation.

If you used the core Spring Framework to configure {geode-name} as a caching provider in
{spring-framework-docs}/integration.html#cache[Spring's Cache Abstraction], you need to:

.Configuring caching using the Spring Framework
====
[source,java]
----
@SpringBootApplication
@EnableCaching
class CachingUsingApacheGeodeConfiguration {

    @Bean
    GemfireCacheManager cacheManager(GemFireCache cache) {

        GemfireCacheManager cacheManager = new GemfireCacheManager();

        cacheManager.setCache(cache);

        return cacheManager;
    }
}
----
====

If you use Spring Data for {geode-name}'s `@EnableGemfireCaching` annotation, you can simplify the preceding
configuration:

.Configuring caching using Spring Data for {geode-name}
====
[source,java]
----
@SpringBootApplication
@EnableGemfireCaching
class CachingUsingApacheGeodeConfiguration {

}
----
====

Also, if you use SBDG, you need only do:

.Configuring caching using Spring Boot for {geode-name}
====
[source,java]
----
@SpringBootApplication
class CachingUsingApacheGeodeConfiguration {

}
----
====

This lets you focus on the areas in your application that would benefit from caching without having to enable the
plumbing. You can then demarcate the service methods in your application that are good candidates for caching:

.Using caching in your application
====
[source,java]
----
@Service
class CustomerService {

    @Caching("CustomersByName")
    Customer findBy(String name) {
        // ...
    }
}
----
====

TIP: See <<geode-caching-provider,documentation on caching>> for more details.

[[geode-configuration-declarative-auto-configuration-enableautocontinuousqueies]]
==== `@EnableContinuousQueries`

NOTE: The SBDG {spring-boot-data-geode-javadoc}/org/springframework/geode/boot/autoconfigure/ContinuousQueryAutoConfiguration.html[`ContinuousQueryAutoConfiguration`] class
corresponds to the SDG {spring-data-geode-javadoc}/org/springframework/data/gemfire/config/annotation/EnableContinuousQueries.html[`@EnableContinuousQueries`] annotation.

Without having to enable anything, you can annotate your application (POJO) component method(s) with the SDG
{spring-data-geode-javadoc}/org/springframework/data/gemfire/listener/annotation/ContinuousQuery.html[`@ContinuousQuery`]
annotation to register a CQ and start receiving events. The method acts as a `CqEvent` handler or, in {geode-name}'s
terminology, the method is an implementation of the
{apache-geode-javadoc}/org/apache/geode/cache/query/CqListener.html[`CqListener`] interface.

.Declare application CQs
====
[source,java]
----
@Component
class MyCustomerApplicationContinuousQueries {

    @ContinuousQuery("SELECT customer.* "
        + " FROM /Customers customers"
        + " WHERE customer.getSentiment().name().equalsIgnoreCase('UNHAPPY')")
    public void handleUnhappyCustomers(CqEvent event) {
        // ...
    }
}
----
====

As the preceding example shows, you can define the events you are interested in receiving by using an OQL query with a
finely tuned query predicate that describes the events of interests and implements the handler method to process the
events (such as applying a credit to the customer's account and following up in email).

TIP: See <<geode-continuous-query>> for more details.

[[geode-configuration-declarative-auto-configuration-enablefunctions]]
==== `@EnableGemfireFunctionExecutions` & `@EnableGemfireFunctions`

NOTE: The SBDG {spring-boot-data-geode-javadoc}/org/springframework/geode/boot/autoconfigure/FunctionExecutionAutoConfiguration.html[`FunctionExecutionAutoConfiguration`] class
corresponds to both the SDG {spring-data-geode-javadoc}/org/springframework/data/gemfire/function/config/EnableGemfireFunctionExecutions.html[`@EnableGemfireFunctionExecutions`]
and SDG {spring-data-geode-javadoc}/org/springframework/data/gemfire/function/config/EnableGemfireFunctions.html[`@EnableGemfireFunctions`] annotations.

Whether you need to {spring-data-geode-docs-html}/#function-execution[execute]
or {spring-data-geode-docs-html}/#function-implementation[implement] a `Function`, SBDG detects the Function definition
and auto-configures it appropriately for use in your Spring Boot application. You need only define the Function
execution or implementation in a package below the main `@SpringBootApplication` class:

.Declare a Function Execution
====
[source,java]
----
package example.app.functions;

@OnRegion("Accounts")
interface MyCustomerApplicationFunctions {

    void applyCredit(Customer customer);

}
----
====

Then you can inject the Function execution into any application component and use it:

.Use the Function
====
[source,java]
----
package example.app.service;

@Service
class CustomerService {

    @Autowired
    private MyCustomerApplicationFunctions customerFunctions;

    void analyzeCustomerSentiment(Customer customer) {

        // ...

        this.customerFunctions.applyCredit(customer);

        // ...
    }
}
----
====

The same pattern basically applies to Function implementations, except in the implementation case, SBDG registers
the Function implementation for use (that is, to be called by a Function execution).

Doing so lets you focus on defining the logic required by your application and not worry about how Functions
are registered, called, and so on. SBDG handles this concern for you.

NOTE: Function implementations are typically defined and registered on the server-side.

TIP: See <<geode-functions>> for more details.

[[geode-configuration-declarative-auto-configuration-enablerepositories]]
==== `@EnableGemfireRepositories`

NOTE: The SBDG {spring-boot-data-geode-javadoc}/org/springframework/geode/boot/autoconfigure/GemFireRepositoriesAutoConfigurationRegistrar.html[`GemFireRepositoriesAutoConfigurationRegistrar`] class
corresponds to the SDG {spring-data-geode-javadoc}/org/springframework/data/gemfire/repository/config/EnableGemfireRepositories.html[`@EnableGemfireRepositories`] annotation.

As with Functions, you need concern yourself only with the data access operations (such as basic CRUD and simple queries)
required by your application to carry out its operation, not with how to create and perform them (for example,
`Region.get(key)` and `Region.put(key, obj)`) or execute them (for example, `Query.execute(arguments)`).

Start by defining your Spring Data Repository:

.Define an application-specific Repository
====
[source,java]
----
package example.app.repo;

interface CustomerRepository extends CrudRepository<Customer, Long> {

    List<Customer> findBySentimentEqualTo(Sentiment sentiment);

}
----
====

Then you can inject the Repository into an application component and use it:

.Using the application-specific Repository
====
[source,java]
----
package example.app.sevice;

@Service
class CustomerService {

    @Autowired
    private CustomerRepository repository;

    public void processCustomersWithSentiment(Sentiment sentiment) {

        this.repository.findBySentimentEqualTo(sentiment)
            .forEach(customer -> { /* ... */ });

        // ...
    }
}
----
====

Your application-specific Repository simply needs to be declared in a package below the main `@SpringBootApplication`
class. Again, you are focusing only on the data access operations and queries required to carry out the operatinons
of your application, nothing more.

TIP: See <<geode-repositories>> for more details.

[[geode-configuration-declarative-auto-configuration-enablelogging]]
==== `@EnableLogging`

NOTE: The SBDG {spring-boot-data-geode-javadoc}/org/springframework/geode/boot/autoconfigure/LoggingAutoConfiguration.html[`LoggingAutoConfiguration`] class
corresponds to the SDG {spring-data-geode-javadoc}/org/springframework/data/gemfire/config/annotation/EnableLogging.html[`@EnableLogging`] annotation.

Logging is an essential application concern to understand what is happening in the system along with when and where
the events occurred. By default, SBDG auto-configures logging for {geode-name} with the default log-level, "`config`".

You can change any aspect of logging, such as the log-level, in Spring Boot `application.properties`:

.Change the log-level for {geode-name}
====
[source,txt]
----
# Spring Boot application.properites.

spring.data.gemfire.cache.log-level=debug
----
====

NOTE: The 'spring.data.gemfire.logging.level' property is an alias for `spring.data.gemfire.cache.log-level`.

You can also configure other aspects, such as the log file size and disk space limits for the filesystem location used
to store the {geode-name} log files at runtime.

Under the hood, {geode-name}'s logging is based on Log4j. Therefore, you can configure {geode-name} logging to use any
logging provider (such as Logback) and configuration metadata appropriate for that logging provider so long as you
supply the necessary adapter between Log4j and whatever logging system you use. For instance, if you include
`org.springframework.boot:spring-boot-starter-logging`, you are using Logback and you will need the
`org.apache.logging.log4j:log4j-to-slf4j` adapter.

[[geode-configuration-declarative-auto-configuration-enablepdx]]
==== `@EnablePdx`

NOTE: The SBDG {spring-boot-data-geode-javadoc}/org/springframework/geode/boot/autoconfigure/PdxSerializationAutoConfiguration.html[`PdxSerializationAutoConfiguration`] class
corresponds to the SDG {spring-data-geode-javadoc}/org/springframework/data/gemfire/config/annotation/EnablePdx.html[`@EnablePdx`] annotation.

Any time you need to send an object over the network or overflow or persist an object to disk, your application domain
model object must be serializable. It would be painful to have to implement `java.io.Serializable` in every one of your
application domain model objects (such as `Customer`) that would potentially need to be serialized.

Furthermore, using Java Serialization may not be ideal (it may not be the most portable or efficient solution) in all
cases or even possible in other cases (such as when you use a third party library over which you have no control).

In these situations, you need to be able to send your object anywhere, anytime without unduly requiring the class type
to be serializable and exist on the classpath in every place it is sent. Indeed, the final destination may not even be
a Java application. This is where {geode-name}
{apache-geode-docs}/developing/data_serialization/gemfire_pdx_serialization.html[PDX Serialization] steps in to help.

However, you need not figure out how to configure PDX to identify the application class types that needs to be
serialized. Instead, you can define your class type as follows:

.Customer class
====
[source,java]
----
@Region("Customers")
class Customer {

    @Id
    private Long id;

    @Indexed
    private String name;

    // ...
}
----
====

SBDG's auto-configuration handles the rest.

TIP: See <<geode-data-serialization>> for more details.

[[geode-configuration-declarative-auto-configuration-enablesecurity]]
==== `@EnableSecurity`

NOTE: The SBDG {spring-boot-data-geode-javadoc}/org/springframework/geode/boot/autoconfigure/ClientSecurityAutoConfiguration.html[`ClientSecurityAutoConfiguration`] class
and {spring-boot-data-geode-javadoc}/org/springframework/geode/boot/autoconfigure/PeerSecurityAutoConfiguration.html[`PeerSecurityAutoConfiguration`] class
correspond to the SDG {spring-data-geode-javadoc}/org/springframework/data/gemfire/config/annotation/EnableSecurity.html[`@EnableSecurity`] annotation,
but they apply security (specifically, authentication and authorization (auth) configuration) for both clients
and servers.

Configuring your Spring Boot, {geode-name} `ClientCache` application to properly authenticate with a cluster of secure
{geode-name} servers is as simple as setting a username and a password in Spring Boot `application.properties`:

.Supplying Authentication Credentials
====
[source,txt]
----
# Spring Boot application.properties

spring.data.gemfire.security.username=Batman
spring.data.gemfire.security.password=r0b!n5ucks
----
====

NOTE: Authentication is even easier to configure in a managed environment, such as PCF when using PCC. You need not do
anything.

Authorization is configured on the server-side and is made simple with SBDG and the help of
https://shiro.apache.org/[Apache Shiro].
Of course, this assumes you use SBDG to configure and bootstrap your {geode-name} cluster in the first place, which is
even easier with SBDG. See <<geode-cluster-configuration-bootstrapping>>.

TIP: See <<geode-security>> for more details.

[[geode-configuration-declarative-auto-configuration-enablessl]]
==== `@EnableSsl`

NOTE: The SBDG {spring-boot-data-geode-javadoc}/org/springframework/geode/boot/autoconfigure/SslAutoConfiguration.html[`SslAutoConfiguration`] class
corresponds to the SDG {spring-data-geode-javadoc}/org/springframework/data/gemfire/config/annotation/EnableSsl.html[`@EnableSsl`] annotation.

Configuring SSL for secure transport (TLS) between your Spring Boot, {geode-name} `ClientCache` application and an
{geode-name} cluster can be a real problem, especially to get right from the start. So, it is something that SBDG
makes as simple as possible.

You can supply a `trusted.keystore` file containing the certificates in a well-known location (such as the root of your
application classpath), and SBDG's auto-configuration steps in to handle the rest.

This is useful during development, but we highly recommend using a more secure procedure (such as integrating with a
secure credential store like LDAP, CredHub or Vault) when deploying your Spring Boot application to production.

TIP: See <<geode-security-ssl>> for more details.

[[geode-configuration-declarative-auto-configuration-enablespringsession]]
==== `@EnableGemFireHttpSession`

NOTE: The SBDG {spring-boot-data-geode-javadoc}/org/springframework/geode/boot/autoconfigure/SpringSessionAutoConfiguration.html[`SpringSessionAutoConfiguration`] class
corresponds to the SSDG {spring-session-data-gemfire-javadoc}/org/springframework/session/data/gemfire/config/annotation/EnableGemFireHttpSession.html[`@EnableGemFireHttpSession`] annotation.

Configuring {geode-name} to serve as the (HTTP) session state caching provider by using Spring Session requires that
you only include the correct starter, that is `spring-geode-starter-session`:

.Using Spring Session
====
[subs="verbatim,attributes"]
----
<dependency>
    <groupId>org.springframework.geode</groupId>
    <artifactId>spring-geode-starter-session</artifactId>
    <version>{revnumber}</version>
</dependency>
----
====

With Spring Session -- and specifically Spring Session for {geode-name} (SSDG) -- on the classpath of your Spring Boot,
{geode-name} `ClientCache` Web application, you can manage your (HTTP) session state with {geode-name}. No further
configuration is needed. SBDG auto-configuration detects Spring Session on the application classpath and does the rest.

TIP: See <<geode-session>> for more details.

[[geode-configuration-declarative-auto-configuration-regiontemplates]]
==== RegionTemplateAutoConfiguration

The SBDG {spring-boot-data-geode-javadoc}/org/springframework/geode/boot/autoconfigure/RegionTemplateAutoConfiguration.html[`RegionTemplateAutoConfiguration`] class
has no corresponding SDG annotation. However, the auto-configuration of a `GemfireTemplate` for every {geode-name}
`Region` defined and declared in your Spring Boot application is still supplied by SBDG.

For example, you can define a Region by using:

.Region definition using JavaConfig
====
[source,java]
----
@Configuration
class GeodeConfiguration {

    @Bean("Customers")
    ClientRegionFactoryBean<Long, Customer> customersRegion(GemFireCache cache) {

        ClientRegionFactoryBean<Long, Customer> customersRegion =
            new ClientRegionFactoryBean<>();

        customersRegion.setCache(cache);
        customersRegion.setShortcut(ClientRegionShortcut.PROXY);

        return customersRegion;
    }
}
----
====

Alternatively, you can define the `Customers` Region by using `@EnableEntityDefinedRegions`:

.Region definition using `@EnableEntityDefinedRegions`
====
[source,java]
----
@Configuration
@EnableEntityDefinedRegion(basePackageClasses = Customer.class)
class GeodeConfiguration {

}
----
====

Then SBDG supplies a `GemfireTemplate` instance that you can use to perform low-level data-access operations
(indirectly) on the `Customers` Region:

.Use the `GemfireTemplate` to access the "Customers" Region
====
[source,java]
----
@Repository
class CustomersDao {

    @Autowired
    @Qualifier("customersTemplate")
    private GemfireTemplate customersTemplate;

    Customer findById(Long id) {
        return this.customerTemplate.get(id);
    }
}
----
====

You need not explicitly configure `GemfireTemplates` for each Region to which you need low-level data access (such as
when you are not using the Spring Data Repository abstraction).

Be careful to qualify the `GemfireTemplate` for the Region to which you need data access, especially given that you
probably have more than one Region defined in your Spring Boot application.

TIP: See <<geode-data-access-region-templates>> for more details.
