Spring/spring-data-geode
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Move Spring Data for Apache Geode documentation (reference docs) to the spring-data-geode-docs Gradle module.

Browse Source 
Resolves #623.
This commit is contained in:
John Blum
2022-09-21 16:48:24 -07:00
parent 518f38b8b5
commit ed133c5cfe
33 changed files with 0 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
spring-data-geode-docs/src/docs/asciidoc/appendix/appendix-schema.adoc Normal file
View File

@@ -0,0 +1,6 @@
[[appendix-schema]]
[appendix]
= {sdg-name} Schema
* {spring-data-schema-location}[{sdg-name} Core Schema (`gfe` XML namespace)]
* {spring-data-access-schema-location}[{sdg-name} Data Access Schema (`gfe-data` XML namespace)]

BIN
spring-data-geode-docs/src/docs/asciidoc/images/epub-cover.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 48 KiB

10
spring-data-geode-docs/src/docs/asciidoc/images/epub-cover.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 8.7 KiB

87
spring-data-geode-docs/src/docs/asciidoc/index.adoc Normal file
View File

@@ -0,0 +1,87 @@
= Spring Data for {data-store-name} Reference Guide
Costin Leau; David Turanski; John Blum; Oliver Gierke; Jay Bryant
:revdate: {localdate}
:revnumber: {version}
:toclevels: 2
:apache-geode-version: 19
:apache-geode-docs: https://geode.apache.org/docs/guide/{apache-geode-version}
:apache-geode-javadoc: https://geode.apache.org/releases/latest/javadoc
:apache-geode-website: https://geode.apache.org
:apache-geode-wiki: https://cwiki.apache.org/confluence/display/GEODE
:data-store-name-symbolic: geode
:data-store-name-simple: Geode
:data-store-name: Apache {data-store-name-simple}
:data-store-version: 1.9.0
:pivotal-gemfire-version: 98
:pivotal-gemfire-docs: https://gemfire.docs.pivotal.io/{pivotal-gemfire-version}
:pivotal-gemfire-javadoc: https://gemfire-{pivotal-gemfire-version}-javadocs.docs.pivotal.io/
:pivotal-gemfire-website: https://pivotal.io/pivotal-gemfire
:pivotal-gemfire-wiki: https://cwiki.apache.org/confluence/display/GEODE
:sdg-acronym: SDG
:sdg-javadoc: https://docs.spring.io/spring-data/{data-store-name-symbolic}/docs/current/api
:sdg-name: Spring Data for {data-store-name}
:sdg-website: https://projects.spring.io/spring-data-gemfire
:spring-data-access-schema-location: https://www.springframework.org/schema/data/geode/spring-data-geode.xsd
:spring-data-access-schema-namespace: https://www.springframework.org/schema/data/geode
:spring-data-commons-docs: https://docs.spring.io/spring-data/commons/docs/current/reference
:spring-data-commons-include: ../../../../spring-data-commons/src/main/asciidoc
:spring-data-commons-docs-html: {spring-data-commons-docs}/html
:spring-data-commons-javadoc: https://docs.spring.io/spring-data/commons/docs/current/api
:spring-data-schema-location: https://www.springframework.org/schema/geode/spring-geode.xsd
:spring-data-schema-namespace: https://www.springframework.org/schema/geode
:spring-data-website: https://spring.io/projects/spring-data
:spring-framework-docs: https://docs.spring.io/spring/docs/current/spring-framework-reference
:spring-framework-javadoc: https://docs.spring.io/spring/docs/current/javadoc-api
:spring-framework-website: https://spring.io/projects/spring-framework
:x-data-store-docs: {apache-geode-docs}
:x-data-store-javadoc: {apache-geode-javadoc}
:x-data-store-website: {apache-geode-website}
:x-data-store-wiki: {apache-geode-wiki}
ifdef::backend-epub3[:front-cover-image: image:epub-cover.png[Front Cover,1050,1600]]
(C) 2010-2022 The original authors.
NOTE: Copies of this document may be made for your own use and for distribution to others provided that you do not
charge any fee for such copies and further provided that each copy contains this Copyright Notice
whether distributed in print or electronically.
[[preface]]
include::{basedocdir}/preface.adoc[]
include::{basedocdir}/introduction/introduction.adoc[leveloffset=+1]
include::{basedocdir}/introduction/requirements.adoc[leveloffset=+1]
include::{basedocdir}/introduction/new-features.adoc[leveloffset=+1]
[[reference]]
= Reference Guide
include::{basedocdir}/reference/introduction.adoc[leveloffset=+1]
include::{basedocdir}/reference/bootstrap.adoc[leveloffset=+1]
include::{basedocdir}/reference/bootstrap-annotations.adoc[leveloffset=+1]
include::{basedocdir}/reference/data.adoc[leveloffset=+1]
include::{basedocdir}/reference/serialization.adoc[leveloffset=+1]
include::{basedocdir}/reference/mapping.adoc[leveloffset=+1]
include::{basedocdir}/reference/repositories.adoc[leveloffset=+1]
include::{basedocdir}/reference/function-annotations.adoc[leveloffset=+1]
include::{basedocdir}/reference/lucene.adoc[leveloffset=+1]
include::{basedocdir}/reference/gemfire-bootstrap.adoc[leveloffset=+1]
include::{basedocdir}/reference/samples.adoc[leveloffset=+1]
[[resources]]
= Resources
In addition to this reference documentation, there are a number of other resources that may help you learn
how to use {data-store-product-name} with the _Spring Framework_. These additional, third-party resources
are enumerated in this section.
include::{basedocdir}/links.adoc[leveloffset=+1]
[[appendices]]
= Appendices
:!sectnums:
include::{spring-data-commons-include}/repository-namespace-reference.adoc[leveloffset=+1]
include::{spring-data-commons-include}/repository-populator-namespace-reference.adoc[leveloffset=+1]
include::{spring-data-commons-include}/repository-query-keywords-reference.adoc[leveloffset=+1]
include::{spring-data-commons-include}/repository-query-return-types-reference.adoc[leveloffset=+1]
include::{basedocdir}/appendix/appendix-schema.adoc[leveloffset=+1]

6
spring-data-geode-docs/src/docs/asciidoc/introduction/introduction.adoc Normal file
View File

@@ -0,0 +1,6 @@
[[introduction]]
= Introduction
The {sdg-name} reference guide explains how to use the Spring Framework
to configure and develop applications with {data-store-name}. It presents the basic concepts
and provides numerous examples to help you get started quickly.

45
spring-data-geode-docs/src/docs/asciidoc/introduction/new-features.adoc Normal file
View File

@@ -0,0 +1,45 @@
[[new-features]]
= New Features
NOTE: As of the 1.2.0.RELEASE, this project, formerly known as Spring GemFire, has been renamed to {sdg-name}
to reflect that it is now a module of the {spring-data-website}[Spring Data] project and built on
{x-data-store-website}[{data-store-name}].
[[new-in-2-0-0]]
== New in the 2.0 Release
* Upgraded to {data-store-name} 9.1.1.
* Upgraded to Spring Data Commons 2.0.8.RELEASE.
* Upgraded to Spring Framework 5.0.7.RELEASE.
* Reorganized the SDG codebase by packaging different classes and components by concern.
* Added extensive support for Java 8 types, particularly in the SD Repository abstraction.
* Changed to the Repository interface and abstraction, e.g. IDs are no longer required to be `java.io.Serializable`.
* Set `@EnableEntityDefinedRegions` annotation `ignoreIfExists` attribute to `true` by default.
* Set `@Indexed` annotation `override` attribute to `false` by default.
* Renamed `@EnableIndexes` to `@EnableIndexing`.
* Introduced a `InterestsBuilder` class to easily and conveniently express Interests in keys and values between client
and server when using JavaConfig.
* Added support in the Annotation configuration model for Off-Heap, Redis Adapter,
and {data-store-name}'s new Security framework.
[[new-in-2-1-0]]
== New in the 2.1 Release
* Upgraded to {data-store-name} {data-store-version}.
* Upgraded to Spring Framework 5.1.0.RELEASE.
* Upgraded to Spring Data Commons 2.1.0.RELEASE.
* Added support for parallel cache/Region snapshots along with invoking callbacks when loading snapshots.
* Added support for registering QueryPostProcessors to customize the OQL generated fro Repository query methods.
* Added support for include/exclude TypeFilters in o.s.d.g.mapping.MappingPdxSerializer.
* Updated docs.
[[new-in-2-2-0]]
== New in the 2.2 Release
* Upgraded to {data-store-name} {data-store-version}.
* Upgraded to Spring Framework 5.2.0.RELEASE.
* Upgraded to Spring Data Commons 2.2.0.RELEASE.
* Add Annotation configuration support to configure and bootstrap {data-store-name} Locator applications
using `@LocatorApplication`.
* Added Annotation configuration support for GatewayReceivers and GatewaySenders.
* Updated docs.

5
spring-data-geode-docs/src/docs/asciidoc/introduction/requirements.adoc Normal file
View File

@@ -0,0 +1,5 @@
[[requirements]]
= Requirements
{sdg-name} requires Java 8.0, {spring-framework-website}[Spring Framework] 5
and {x-data-store-website}[{data-store-name}] {data-store-version}.

14
spring-data-geode-docs/src/docs/asciidoc/links.adoc Normal file
View File

@@ -0,0 +1,14 @@
[[sgf-links]]
= Useful Links
* https://projects.spring.io/spring-data-gemfire[{sdg-name} Project Page]
* https://github.com/spring-projects/spring-data-gemfire[{sdg-name} source code]
* https://jira.spring.io/browse/SGF[{sdg-name} JIRA]
* https://stackoverflow.com/questions/tagged/spring-data-gemfire[{sdg-name} on StackOverflow]
* https://forum.spring.io/forum/spring-projects/data/gemfire[Archive of the {sdg-name} Forum on Spring IO]
* {x-data-store-website}[{data-store-name} Home Page]
* {x-data-store-docs}/getting_started/book_intro.html[{data-store-name} Documentation]
* {apache-geode-website}/community/[Apache Geode Community]
* https://github.com/apache/geode[Apache Geode source code]
* https://issues.apache.org/jira/projects/GEODE/issues[Apache Geode JIRA]
* https://stackoverflow.com/questions/tagged/gemfire[{data-store-name} on StackOverflow]

14
spring-data-geode-docs/src/docs/asciidoc/preface.adoc Normal file
View File

@@ -0,0 +1,14 @@
= Preface
{sdg-name} focuses on integrating the Spring Framework's powerful, non-invasive programming model
and concepts with {data-store-name} to simplify configuration and development of Java applications
when using {data-store-name} as you data management solution.
This document assumes you already have a basic understanding of, and some familiarity with, the core Spring Framework
and {data-store-name} concepts.
While every effort has been made to ensure this documentation is comprehensive and complete without errors,
some topics are beyond the scope of this document and may require more explanation (for example, data distribution management
using partitioning with HA while still preserving consistency). Additionally, some typographical errors might have crept in.
If you do spot mistakes or even more serious errors, please bring these issues to the attention of the Spring Data team
by raising an appropriate https://jira.spring.io/browse/SGF[issue in JIRA].

733
spring-data-geode-docs/src/docs/asciidoc/reference/bootstrap-annotations-quickstart.adoc Normal file
View File

@@ -0,0 +1,733 @@
[[bootstap-annotations-quickstart]]
= Annotation-based Configuration Quick Start
The following sections provide an overview to the {sdg-acronym} annotations in order to get started quickly.
NOTE: All annotations provide additional configuration attributes along with associated <<bootstrap-annotation-config-properties, properties>>
to conveniently customize the configuration and behavior of {data-store-name} at runtime. However, in general,
none of the attributes or associated properties are required to use a particular {data-store-name} feature.
Simply declare the annotation to enable the feature and you are done. Refer to the individual Javadoc of
each annotation for more details.
[[bootstap-annotations-quickstart-clientcache]]
== Configure a `ClientCache` Application
To configure and bootstrap a {data-store-name} `ClientCache` application, use the following:
[source,java]
----
@SpringBootApplication
@ClientCacheApplication
public class ClientApplication {
public static void main(String[] args) {
SpringApplication.run(ClientApplication.class, args);
}
}
----
See {sdg-javadoc}/org/springframework/data/gemfire/config/annotation/ClientCacheApplication.html[`@ClientCacheApplication` Javadoc].
See <<bootstrap-annotation-config-geode-applications>> for more details.
[[bootstap-annotations-quickstart-peercache]]
== Configure a Peer `Cache` Application
To configure and bootstrap a {data-store-name} Peer `Cache` application, use the following:
[source,java]
----
@SpringBootApplication
@PeerCacheApplication
public class ServerApplication {
public static void main(String[] args) {
SpringApplication.run(ServerApplication.class, args);
}
}
----
NOTE: If you would like to enable a `CacheServer` that allows `ClientCache` applications to connect to this server,
then simply replace the `@PeerCacheApplication` annotation with the `@CacheServerApplication` annotation. This will
start a `CacheServer` running on "`localhost`", listening on the default `CacheServer` port of `40404`.
See {sdg-javadoc}/org/springframework/data/gemfire/config/annotation/CacheServerApplication.html[`@CacheServerApplication` Javadoc].
See {sdg-javadoc}/org/springframework/data/gemfire/config/annotation/PeerCacheApplication.html[`@PeerCacheApplication` Javadoc].
See <<bootstrap-annotation-config-geode-applications>> for more details.
[[bootstap-annotations-quickstart-locator]]
== Configure an Embedded Locator
Annotate your Spring `@PeerCacheApplication` or `@CacheServerApplication` class with `@EnableLocator` to start
an embedded Locator bound to all NICs listening on the default Locator port, `10334`, as follows:
[source,java]
----
@SpringBootApplication
@CacheServerApplication
@EnableLocator
public class ServerApplication {
public static void main(String[] args) {
SpringApplication.run(ServerApplication.class, args);
}
}
----
NOTE: `@EnableLocator` can only be used with {data-store-name} server applications.
See {sdg-javadoc}/org/springframework/data/gemfire/config/annotation/EnableLocator.html[`@EnableLocator` Javadoc].
See <<bootstrap-annotation-config-embedded-services-locator>> for more details.
[[bootstap-annotations-quickstart-manager]]
== Configure an Embedded Manager
Annotate your Spring `@PeerCacheApplication` or `@CacheServerApplication` class with `@EnableManager` to start
an embedded Manager bound to all NICs listening on the default Manager port, `1099`, as follows:
[source,java]
----
@SpringBootApplication
@CacheServerApplication
@EnableManager
public class ServerApplication {
public static void main(String[] args) {
SpringApplication.run(ServerApplication.class, args);
}
}
----
NOTE: `@EnableManager` can only be used with {data-store-name} server applications.
See {sdg-javadoc}/org/springframework/data/gemfire/config/annotation/EnableManager.html[`@EnableManager` Javadoc].
See <<bootstrap-annotation-config-embedded-services-manager>> for more details.
[[bootstap-annotations-quickstart-httpserver]]
== Configure the Embedded HTTP Server
Annotate your Spring `@PeerCacheApplication` or `@CacheServerApplication` class with `@EnableHttpService` to start
the embedded HTTP server (Jetty) listening on port `7070`, as follows:
[source,java]
----
@SpringBootApplication
@CacheServerApplication
@EnableHttpService
public class ServerApplication {
public static void main(String[] args) {
SpringApplication.run(ServerApplication.class, args);
}
}
----
NOTE: `@EnableHttpService` can only be used with {data-store-name} server applications.
See {sdg-javadoc}/org/springframework/data/gemfire/config/annotation/EnableHttpService.html[`@EnableHttpService` Javadoc].
See <<bootstrap-annotation-config-embedded-services-http>> for more details.
[[bootstap-annotations-quickstart-memcachedserver]]
== Configure the Embedded Memcached Server
Annotate your Spring `@PeerCacheApplication` or `@CacheServerApplication` class with `@EnableMemcachedServer` to start
the embedded Memcached server (Gemcached) listening on port `11211`, as follows:
[source,java]
----
@SpringBootApplication
@CacheServerApplication
@EnableMemcachedServer
public class ServerApplication {
public static void main(String[] args) {
SpringApplication.run(ServerApplication.class, args);
}
}
----
NOTE: `@EnableMemcachedServer` can only be used with {data-store-name} server applications.
See {sdg-javadoc}/org/springframework/data/gemfire/config/annotation/EnableMemcachedServer.html[`@EnableMemcachedServer` Javadoc].
See <<bootstrap-annotation-config-embedded-services-memcached>> for more details.
[[bootstap-annotations-quickstart-logging]]
== Configure Logging
To configure or adjust {data-store-name} logging, annotate your Spring, {data-store-name} client or server
application class with `@EnableLogging`, as follows:
[source,java]
----
@SpringBootApplication
@ClientCacheApplication
@EnableLogging(logLevel="trace")
public class ClientApplication {
public static void main(String[] args) {
SpringApplication.run(ClientApplication.class, args);
}
}
----
NOTE: Default `log-level` is "`config`". Also, this annotation will not adjust log levels in your application,
only for {data-store-name}.
See {sdg-javadoc}/org/springframework/data/gemfire/config/annotation/EnableLogging.html[`@EnableLogging` Javadoc].
See <<bootstrap-annotation-config-logging>> for more details.
[[bootstap-annotations-quickstart-statistics]]
== Configure Statistics
To gather {data-store-name} statistics at runtime, annotate your Spring, {data-store-name} client or server
application class with `@EnableStatistics`, as follows:
[source,java]
----
@SpringBootApplication
@ClientCacheApplication
@EnableStatistics
public class ClientApplication {
public static void main(String[] args) {
SpringApplication.run(ClientApplication.class, args);
}
}
----
See {sdg-javadoc}/org/springframework/data/gemfire/config/annotation/EnableStatistics.html[`@EnableStatistics` Javadoc].
See <<bootstrap-annotation-config-statistics>> for more details.
[[bootstap-annotations-quickstart-pdx]]
== Configure PDX
To enable {data-store-name} PDX serialization, annotate your Spring, {data-store-name} client or server
application class with `@EnablePdx`, as follows:
[source,java]
----
@SpringBootApplication
@ClientCacheApplication
@EnablePdx
public class ClientApplication {
public static void main(String[] args) {
SpringApplication.run(ClientApplication.class, args);
}
}
----
NOTE: {data-store-name} PDX Serialization is an alternative to Java Serialization with many added benefits. For one,
it makes short work of making all of your application domain model types serializable without having to implement
`java.io.Serializable`.
NOTE: By default, {sdg-acronym} configures the `MappingPdxSerializer` to serialize your application domain model types,
which does not require any special configuration out-of-the-box in order to properly identify application domain objects
that need to be serialized and then perform the serialization since, the logic in `MappingPdxSerializer` is based on
Spring Data's mapping infrastructure. See <<mapping.pdx-serializer>> for more details.
See {sdg-javadoc}/org/springframework/data/gemfire/config/annotation/EnablePdx.html[`@EnablePdx` Javadoc].
See <<bootstrap-annotation-config-pdx>> for more details.
[[bootstap-annotations-quickstart-ssl]]
== Configure SSL
To enable {data-store-name} SSL, annotate your Spring, {data-store-name} client or server application class
with `@EnableSsl`, as follows:
[source,java]
----
@SpringBootApplication
@ClientCacheApplication
@EnableSsl(components = SERVER)
public class ClientApplication {
public static void main(String[] args) {
SpringApplication.run(ClientApplication.class, args);
}
}
----
NOTE: Minimally, {data-store-name} requires you to specify a keystore & truststore using the appropriate configuration
attributes or properties. Both keystore & truststore configuration attributes or properties may refer to the same
`KeyStore` file. Additionally, you will need to specify a username and password to access the `KeyStore` file
if the file has been secured.
NOTE: {data-store-name} SSL allows you to configure the specific components of the system that require TLS, such as
client/server, Locators, Gateways, etc. Optionally, you can specify that all components of {data-store-name}
use SSL with "`ALL`".
See {sdg-javadoc}/org/springframework/data/gemfire/config/annotation/EnableSsl.html[`@EnableSsl` Javadoc].
See <<bootstrap-annotation-config-ssl>> for more details.
[[bootstap-annotations-quickstart-security]]
== Configure Security
To enable {data-store-name} security, annotate your Spring, {data-store-name} client or server application class
with `@EnableSecurity`, as follows:
[source,java]
----
@SpringBootApplication
@ClientCacheApplication
@EnableSecurity
public class ClientApplication {
public static void main(String[] args) {
SpringApplication.run(ClientApplication.class, args);
}
}
----
NOTE: On the server, you must configure access to the auth credentials. You may either implement the {data-store-name}
{x-data-store-javadoc}/org/apache/geode/security/SecurityManager.html[`SecurityManager`] interface or declare
1 or more Apache Shiro `Realms`. See <<bootstrap-annotation-config-security-server>> for more details.
NOTE: On the client, you must configure a username and password. See <<bootstrap-annotation-config-security-client>>
for more details.
See {sdg-javadoc}/org/springframework/data/gemfire/config/annotation/EnableSecurity.html[`@EnableSecurity` Javadoc].
See <<bootstrap-annotation-config-security>> for more details.
[[bootstap-annotations-quickstart-properties]]
== Configure {data-store-name} Properties
To configure other, low-level {data-store-name} properties not covered by the feature-oriented, {sdg-acronym}
configuration annotations, annotate your Spring, {data-store-name} client or server application class
with `@GemFireProperties`, as follows:
[source,java]
----
@SpringBootApplication
@PeerCacheApplication
@EnableGemFireProperties(
cacheXmlFile = "/path/to/cache.xml",
conserveSockets = true,
groups = "GroupOne",
remoteLocators = "lunchbox[11235],mailbox[10101],skullbox[12480]"
)
public class ServerApplication {
public static void main(String[] args) {
SpringApplication.run(ServerApplication.class, args);
}
}
----
NOTE: Some {data-store-name} properties are client-side only while others are server-side only. Please review the
{data-store-name} {x-data-store-docs}/reference/topics/gemfire_properties.html[docs] for the appropriate use
of each property.
See {sdg-javadoc}/org/springframework/data/gemfire/config/annotation/EnableGemFireProperties.html[`@EnableGemFireProperties` Javadoc].
See <<bootstrap-annotation-config-gemfire-properties>> for more details.
[[bootstap-annotations-quickstart-caching]]
== Configure Caching
To use {data-store-name} as a _caching provider_ in Spring's {spring-framework-docs}/integration.html#cache[_Cache Abstraction_],
and have {sdg-acronym} automatically create {data-store-name} Regions for the caches required by your application
service components, then annotate your Spring, {data-store-name} client or server application class
with `@EnableGemfireCaching` and `@EnableCachingDefinedRegions`, as follows:
[source,java]
----
@SpringBootApplication
@ClientCacheApplication
@EnableCachingDefinedRegions
@EnableGemfireCaching
public class ClientApplication {
public static void main(String[] args) {
SpringApplication.run(ClientApplication.class, args);
}
}
----
Then, simply go on to define the application services that require caching, as follows:
[source,java]
----
@Service
public class BookService {
@Cacheable("Books")
public Book findBy(ISBN isbn) {
...
}
}
----
NOTE: `@EnableCachingDefinedRegions` is optional. That is, you may manually define your Regions if you desire.
See {sdg-javadoc}/org/springframework/data/gemfire/config/annotation/EnableCachingDefinedRegions.html[`@EnableCachingDefinedRegions` Javadoc].
See {sdg-javadoc}/org/springframework/data/gemfire/cache/config/EnableGemfireCaching.html[`@EnableGemfireCaching` Javadoc].
See <<bootstrap-annotation-config-caching>> for more details.
[[bootstap-annotations-quickstart-repositories]]
== Configure Regions, Indexes, Repositories and Entities for Persistent Applications
To make short work of creating Spring, {data-store-name} persistent client or server applications, annotate your
application class with `@EnableEntityDefinedRegions`, `@EnableGemfireRepositories` and `@EnableIndexing`, as follows:
[source,java]
----
@SpringBootApplication
@ClientCacheApplication
@EnableEntityDefinedRegions(basePackageClasses = Book.class)
@EnableGemfireRepositories(basePackageClasses = BookRepository.class)
@EnableIndexing
public class ClientApplication {
public static void main(String[] args) {
SpringApplication.run(ClientApplication.class, args);
}
}
----
NOTE: The `@EnableEntityDefinedRegions` annotation is required when using the `@EnableIndexing` annotation.
See <<bootstrap-annotation-config-region-indexes>> for more details.
Next, define your entity class and use the `@Region` mapping annotation to specify the Region in which your entity
will be stored. Use the `@Indexed` annotation to define Indexes on entity fields used in your application queries,
as follows:
[source,java]
----
package example.app.model;
import ...;
@Region("Books")
public class Book {
@Id
private ISBN isbn;
@Indexed;
private Author author;
@Indexed
private LocalDate published;
@LuceneIndexed
private String title;
}
----
NOTE: The `@Region("Books")` entity class annotation is used by the `@EnableEntityDefinedRegions` to determine
the Regions required by the application. See <<bootstrap-annotation-config-region-types>> and <<mapping>>
for more details.
Finally, define your CRUD Repository with simple queries to persist and access `Books`, as follows:
[source,java]
----
package example.app.repo;
import ...;
public interface BookRepository extends CrudRepository {
List<Book> findByAuthorOrderByPublishedDesc(Author author);
}
----
TIP: See <<gemfire-repositories>> for more details.
See {sdg-javadoc}/org/springframework/data/gemfire/config/annotation/EnableEntityDefinedRegions.html[`@EnableEntityDefinedRegions` Javadoc].
See {sdg-javadoc}/org/springframework/data/gemfire/repository/config/EnableGemfireRepositories.html[`@EnableGemfireRepositories` Javadoc].
See {sdg-javadoc}/org/springframework/data/gemfire/config/annotation/EnableIndexing.html[`@EnableIndexing` Javadoc].
See {sdg-javadoc}/org/springframework/data/gemfire/mapping/annotation/Region.html[`@Region` Javadoc].
See {sdg-javadoc}/org/springframework/data/gemfire/mapping/annotation/Indexed.html[`@Indexed` Javadoc].
See {sdg-javadoc}/org/springframework/data/gemfire/mapping/annotation/LuceneIndexed.html[`@LuceneIndexed` Javadoc].
See <<bootstrap-annotation-config-regions>> for more details.
See <<gemfire-repositories>> for more details.
[[bootstap-annotations-quickstart-cluster-defined-regions]]
== Configure Client Regions from Cluster-defined Regions
Alternatively, you can define client [*PROXY] Regions from Regions already defined in the cluster
using `@EnableClusterDefinedRegions`, as follows:
[source,java]
----
@SpringBootApplication
@ClientCacheApplication
@EnableClusterDefinedRegions
@EnableGemfireRepositories
public class ClientApplication {
public static void main(String[] args) {
SpringApplication.run(ClientApplication.class, args);
}
...
}
----
See <<bootstrap-annotation-config-region-cluster-defined>> for more details.
[[bootstap-annotations-quickstart-functions]]
== Configure Functions
{data-store-name} Functions are useful in distributed compute scenarios where a potentially expensive computation
requiring data can be performed in parallel across the nodes in the cluster. In this case, it is more efficient
to bring the logic to where the data is located (stored) rather than requesting and fetching the data to be processed
by the computation.
Use the `@EnableGemfireFunctions` along with the `@GemfireFunction` annotation to enable {data-store-name} Functions
definitions implemented as methods on POJOs, as follows:
[source, java]
----
@PeerCacheApplication
@EnableGemfireFunctions
class ServerApplication {
public static void main(String[] args) {
SpringApplication.run(ServerApplication.class, args);
}
@GemfireFunction
Integer computeLoyaltyPoints(Customer customer) {
...
}
}
----
Use the `@EnableGemfireFunctionExecutions` along with 1 of the Function calling annotations: `@OnMember`, `@OnMembers`,
`@OnRegion`, `@OnServer` and `@OnServers`.
[source, java]
----
@ClientCacheApplication
@EnableGemfireFunctionExecutions(basePackageClasses = CustomerRewardsFunction.class)
class ClientApplication {
public static void main(String[] args) {
SpringApplication.run(ClientApplication.class, args);
}
}
@OnRegion("Customers")
interface CustomerRewardsFunctions {
Integer computeLoyaltyPoints(Customer customer);
}
----
See {sdg-javadoc}/org/springframework/data/gemfire/function/config/EnableGemfireFunctions.html[`@EnableGemfireFunctions` Javadoc].
See {sdg-javadoc}/org/springframework/data/gemfire/function/annotation/GemfireFunction.html[`@GemfireFunction` Javadoc].
See {sdg-javadoc}/org/springframework/data/gemfire/function/config/EnableGemfireFunctionExecutions.html[`@EnableGemfireFunctionExecutions` Javadoc].
See {sdg-javadoc}/org/springframework/data/gemfire/function/annotation/OnMember.html[`@OnMember` Javadoc],
{sdg-javadoc}/org/springframework/data/gemfire/function/annotation/OnMembers.html[`@OnMembers` Javadoc],
{sdg-javadoc}/org/springframework/data/gemfire/function/annotation/OnRegion.html[`@OnRegion` Javadoc],
{sdg-javadoc}/org/springframework/data/gemfire/function/annotation/OnServer.html[`@OnServer` Javadoc],
and {sdg-javadoc}/org/springframework/data/gemfire/function/annotation/OnServers.html[`@OnServers` Javadoc].
See <<function-annotations>> for more details.
[[bootstap-annotations-quickstart-continuousquery]]
== Configure Continuous Query
Real-time, event stream processing is becoming an increasingly important task for data-intensive applications,
primarily in order to respond to user requests in a timely manner. {data-store-name} Continuous Query (CQ)
will help you achieve this rather complex task quite easily.
Enable CQ by annotating your application class with `@EnableContinuousQueries` and define your CQs along with
the associated event handlers, as follows:
[source,java]
----
@ClientCacheApplication
@EnableContinuousQueries
class ClientApplication {
public static void main(String[] args) {
SpringApplication.run(ClientApplication.class, args);
}
}
----
Then, define your CQs by annotating the associated handler method with `@ContinousQuery`, as follows:
[source,java]
----
@Service
class CustomerService {
@ContinuousQuery(name = "CustomerQuery", query = "SELECT * FROM /Customers c WHERE ...")
public void process(CqEvent event) {
...
}
}
----
Anytime an event occurs changing the `Customer` data to match the predicate in your continuous OQL query (CQ),
the `process` method will be called.
NOTE: {data-store-name} CQ is a client-side feature only.
See {sdg-javadoc}/org/springframework/data/gemfire/config/annotation/EnableContinuousQueries.html[`@EnableContinuousQueries` Javadoc].
See {sdg-javadoc}/org/springframework/data/gemfire/listener/annotation/ContinuousQuery.html[`@ContinuousQuery` Javadoc].
See <<apis:continuous-query>> and <<bootstrap-annotation-config-continuous-queries>> for more details.
[[bootstap-annotations-quickstart-cluster-configuration]]
== Configure Cluster Configuration
When developing Spring Data applications using {data-store-name} as {data-store-name} `ClientCache` applications, it is
useful during development to configure the server to match the client in a client/server topology. In fact,
{data-store-name} expects that when you have a "/Example" PROXY `Region` on the client, that a matching `Region` by name
(i.e. "Example") exists in the server.
You could use _Gfsh_ to create every Region and Index that your application requires, or, you could simply push
the configuration meta-data already expressed when developing your Spring Data application using {data-store-name}
when you run it.
This is as simple as annotation your main application class with `@EnableClusterConfiguration(..)`:
.Using `@EnableClusterConfiguration`
[source,java]
----
@ClientCacheApplication
@EnableClusterConfiguration(useHttp = true)
class ClientApplication {
...
}
----
NOTE: Most of the time, when using a client/server topology, particularly in production environments, the servers
of the cluster will be started using _Gfsh_. In which case, it customary to use HTTP(S) to send the configuration
metadata (e.g. Region & Index definitions) to the cluster. When HTTP is used, the configuration metadata is sent
to the Manager in the cluster and distributed across the server nodes in the cluster consistently.
WARNING: In order to use `@EnableClusterConfiguration` you must declare the `org.springframework:spring-web` dependency
in your Spring application classpath.
See {sdg-javadoc}/org/springframework/data/gemfire/config/annotation/EnableClusterConfiguration.html[`@EnableClusterConfiguration` Javadoc].
See <<bootstrap-annotation-config-cluster>> for more details.
[[bootstap-annotations-quickstart-gatewayreceiver]]
== Configure `GatewayReceivers`
The replication of data between different {data-store-name} clusters is an increasingly important fault-tolerance
and high-availability (HA) mechanism. {data-store-name} WAN replication is a mechanism that allows one
{data-store-name} cluster to replicate its data to another {data-store-name} cluster in a reliable and fault-tolerant
manner.
{data-store-name} WAN replication requires two components to be configured:
* `GatewayReceiver` - The WAN replication component that receives data from a remote {data-store-name} cluster's `GatewaySender`.
* `GatewaySender` - The WAN replication component that sends data to a remote {data-store-name} cluster's `GatewayReceiver`.
To enable a `GatewayReceiver`, the application class needs to be annotated with `@EnableGatewayReceiver` as follows:
[source,java]
----
@CacheServerApplication
@EnableGatewayReceiver(manualStart = false, startPort = 10000, endPort = 11000, maximumTimeBetweenPings = 1000,
socketBufferSize = 16384, bindAddress = "localhost",transportFilters = {"transportBean1", "transportBean2"},
hostnameForSenders = "hostnameLocalhost"){
...
...
}
}
class MySpringApplication { .. }
----
NOTE: {data-store-name} `GatewayReceiver` is a server-side feature only and can only be configured on a `CacheServer`
or peer `Cache` node.
See {sdg-javadoc}/org/springframework/data/gemfire/wan/annotation/EnableGatewayReceiver.html[`@EnableGatewayReceiver` Javadoc].
[[bootstap-annotations-quickstart-gatewaysenders]]
== Configure `GatewaySenders`
To enable `GatewaySender`, the application class needs to be annotated with `@EnableGatewaySenders`
and `@EnableGatewaySender` as follows:
[source,java]
----
@CacheServerApplication
@EnableGatewaySenders(gatewaySenders = {
@EnableGatewaySender(name = "GatewaySender", manualStart = true,
remoteDistributedSystemId = 2, diskSynchronous = true, batchConflationEnabled = true,
parallel = true, persistent = false,diskStoreReference = "someDiskStore",
orderPolicy = OrderPolicyType.PARTITION, alertThreshold = 1234, batchSize = 100,
eventFilters = "SomeEventFilter", batchTimeInterval = 2000, dispatcherThreads = 22,
maximumQueueMemory = 400,socketBufferSize = 16384,
socketReadTimeout = 4000, regions = { "Region1"}),
@EnableGatewaySender(name = "GatewaySender2", manualStart = true,
remoteDistributedSystemId = 2, diskSynchronous = true, batchConflationEnabled = true,
parallel = true, persistent = false, diskStoreReference = "someDiskStore",
orderPolicy = OrderPolicyType.PARTITION, alertThreshold = 1234, batchSize = 100,
eventFilters = "SomeEventFilter", batchTimeInterval = 2000, dispatcherThreads = 22,
maximumQueueMemory = 400, socketBufferSize = 16384,socketReadTimeout = 4000,
regions = { "Region2" })
}){
class MySpringApplication { .. }
}
----
NOTE: {data-store-name} `GatewaySender` is a server-side feature only and can only be configured on a `CacheServer`
or a peer `Cache` node.
In the above example, the application is configured with 2 Regions, `Region1` and `Region2`. In addition,
two `GatewaySenders` will be configured to service both Regions. `GatewaySender1` will be configured to replicate
`Region1`'s data and `GatewaySender2` will be configured to replicate `Region2`'s data.
As demonstrated each `GatewaySender` property can be configured on each `EnableGatewaySender` annotation.
It is also possible to have a more generic, "defaulted" properties approach, where all properties are configured on
the `EnableGatewaySenders` annotation. This way, a set of generic, defaulted values can be set on the parent annotation
and then overridden on the child if required, as demonstrated below:
[source,java]
----
@CacheServerApplication
@EnableGatewaySenders(gatewaySenders = {
@EnableGatewaySender(name = "GatewaySender", transportFilters = "transportBean1", regions = "Region2"),
@EnableGatewaySender(name = "GatewaySender2")},
manualStart = true, remoteDistributedSystemId = 2,
diskSynchronous = false, batchConflationEnabled = true, parallel = true, persistent = true,
diskStoreReference = "someDiskStore", orderPolicy = OrderPolicyType.PARTITION, alertThreshold = 1234, batchSize = 1002,
eventFilters = "SomeEventFilter", batchTimeInterval = 2000, dispatcherThreads = 22, maximumQueueMemory = 400,
socketBufferSize = 16384, socketReadTimeout = 4000, regions = { "Region1", "Region2" },
transportFilters = { "transportBean2", "transportBean1" })
class MySpringApplication { .. }
----
NOTE: When the `regions` attribute is left empty or not populated, the `GatewaySender`(s) will automatically attach
itself to every configured `Region` within the application.
See {sdg-javadoc}/org/springframework/data/gemfire/wan/annotation/EnableGatewaySenders.html[`@EnableGatewaySenders` Javadoc]
and {sdg-javadoc}/org/springframework/data/gemfire/wan/annotation/EnableGatewaySender.html[`@EnableGatewaySender` Javadoc].

2444
spring-data-geode-docs/src/docs/asciidoc/reference/bootstrap-annotations.adoc Normal file
View File

File diff suppressed because it is too large Load Diff

115
spring-data-geode-docs/src/docs/asciidoc/reference/bootstrap.adoc Normal file
View File

@@ -0,0 +1,115 @@
[[bootstrap]]
= Bootstrapping {data-store-name} with the Spring Container
{sdg-name} provides full configuration and initialization of the {data-store-name} In-Memory Data Grid (IMDG)
using the Spring IoC container. The framework includes several classes to help simplify the configuration of
{data-store-name} components, including: Caches, Regions, Indexes, DiskStores, Functions, WAN Gateways,
persistence backup, and several other Distributed System components to support a variety of application use cases
with minimal effort.
NOTE: This section assumes basic familiarity with {data-store-name}. For more information, see the {data-store-name}
{x-data-store-docs}/gemfire/about_gemfire.html[product documentation].
[[bootstrap:namespace:xml]]
== Advantages of using Spring over {data-store-name} `cache.xml`
{sdg-name}'s XML namespace supports full configuration of the {data-store-name} In-Memory Data Grid (IMDG).
The XML namespace is one of two ways to configure {data-store-name} in a Spring context in order to properly manage
{data-store-name}'s lifecycle inside the Spring container. The other way to configure {data-store-name} in a Spring
context is by using <<bootstrap-annotation-config,annotation-based configuration>>.
While support for {data-store-name}'s native `cache.xml` persists for legacy reasons, {data-store-name} application developers
who use XML configuration are encouraged to do everything in Spring XML to take advantage of the many wonderful things
Spring has to offer, such as modular XML configuration, property placeholders and overrides,
SpEL ({spring-framework-docs}/core.html#expressions[Spring Expression Language]), and environment profiles.
Behind the XML namespace, {sdg-name} makes extensive use of Spring's `FactoryBean` pattern to simplify the creation,
configuration, and initialization of {data-store-name} components.
{data-store-name} provides several callback interfaces, such as `CacheListener`, `CacheLoader`, and `CacheWriter`,
that let developers add custom event handlers. Using Spring's IoC container, you can configure these callbacks
as normal Spring beans and inject them into {data-store-name} components. This is a significant improvement over
native `cache.xml`, which provides relatively limited configuration options and requires callbacks to implement
{data-store-name}'s `Declarable` interface (see <<apis:declarable>> to see how you can still use `Declarables`
within Spring's container).
In addition, IDEs, such as the Spring Tool Suite (STS), provide excellent support for Spring XML namespaces,
including code completion, pop-up annotations, and real time validation.
[[bootstrap:namespace]]
== Using the Core Namespace
To simplify configuration, {sdg-name} provides a dedicated XML namespace for configuring core {data-store-name}
components. It is possible to configure beans directly by using Spring's standard `<bean>` definition. However,
all bean properties are exposed through the XML namespace, so there is little benefit to using raw bean definitions.
NOTE: For more information about XML Schema-based configuration in Spring, see the
{spring-framework-docs}/core.html#appendix[appendix] in the Spring Framework reference documentation.
NOTE: Spring Data Repository support uses a separate XML namespace. See <<gemfire-repositories>> for more information
on how to configure {sdg-name} Repositories.
To use the {sdg-name} XML namespace, declare it in your Spring XML configuration meta-data,
as the following example shows:
[source,xml]
[subs="verbatim,attributes"]
----
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:gfe="{spring-data-schema-namespace}" <!--1--><!--2-->
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
{spring-data-schema-namespace} {spring-data-schema-location} <!--3-->
">
<bean id ... >
<gfe:cache ...> <!--4-->
</beans>
----
<1> {sdg-name} XML namespace prefix. Any name works, but, throughout this reference documentation, `gfe` is used.
<2> The XML namespace prefix is mapped to the URI.
<3> The XML namespace URI location. Note that, even though the location points to an external address (which does exist
and is valid), Spring resolves the schema locally, as it is included in the {sdg-name} library.
<4> Example declaration using the XML namespace with the `gfe` prefix.
[NOTE]
====
You can change the default namespace from `beans` to `gfe`. This is useful for XML configuration composed mainly of
{data-store-name} components, as it avoids declaring the prefix. To do so, swap the namespace prefix declaration
shown earlier, as the following example shows:
[source,xml]
[subs="verbatim,attributes"]
----
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="{spring-data-schema-namespace}" <!--1-->
xmlns:beans="http://www.springframework.org/schema/beans" <!--2-->
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
{spring-data-schema-namespace} {spring-data-schema-location}
">
<beans:bean id ... > <!--3-->
<cache ...> <!--4-->
</beans>
----
<1> The default namespace declaration for this XML document points to the {sdg-name} XML namespace.
<2> The `beans` namespace prefix declaration for Spring's raw bean definitions.
<3> Bean declaration using the `beans` namespace. Notice the prefix.
<4> Bean declaration using the `gfe` namespace. Notice the lack of prefix since `gfe` is the default namespace.
====
include::{basedocdir}/reference/data-access.adoc[leveloffset=+1]
include::{basedocdir}/reference/cache.adoc[leveloffset=+1]
include::{basedocdir}/reference/region.adoc[leveloffset=+1]
include::{basedocdir}/reference/indexing.adoc[leveloffset=+1]
include::{basedocdir}/reference/diskstore.adoc[leveloffset=+1]
include::{basedocdir}/reference/snapshot.adoc[leveloffset=+1]
include::{basedocdir}/reference/function.adoc[leveloffset=+1]
include::{basedocdir}/reference/gateway.adoc[leveloffset=+1]

437
spring-data-geode-docs/src/docs/asciidoc/reference/cache.adoc Normal file
View File

@@ -0,0 +1,437 @@
[[bootstrap:cache]]
= Configuring a Cache
To use {data-store-name}, you need to either create a new cache or connect to an existing one. With the current version
of {data-store-name}, you can have only one open cache per VM (more strictly speaking, per `ClassLoader`). In most cases,
the cache should only be created once.
NOTE: This section describes the creation and configuration of a peer `Cache` member, appropriate in peer-to-peer (P2P)
topologies and cache servers. A `Cache` member can also be used in stand-alone applications and integration tests.
However, in typical production systems, most application processes act as cache clients, creating a `ClientCache`
instance instead. This is described in the <<bootstrap:cache:client>> and <<bootstrap:region:client>> sections.
A peer `Cache` with default configuration can be created with the following simple declaration:
[source,xml]
----
<gfe:cache/>
----
During Spring container initialization, any `ApplicationContext` containing this cache definition registers a
`CacheFactoryBean` that creates a Spring bean named `gemfireCache`, which references a {data-store-name} `Cache` instance.
This bean refers to either an existing `Cache` or, if one does not already exist, a newly created one. Since no
additional properties were specified, a newly created `Cache` applies the default cache configuration.
All {sdg-name} components that depend on the `Cache` respect this naming convention, so you need not explicitly declare
the `Cache` dependency. If you prefer, you can make the dependency explicit by using the `cache-ref` attribute provided
by various {sdg-acronym} XML namespace elements. Also, you can override the cache's bean name using the `id` attribute,
as follows:
[source,xml]
----
<gfe:cache id="myCache"/>
----
A {data-store-name} `Cache` can be fully configured using Spring. However, {data-store-name}'s native XML configuration
file, `cache.xml`, is also supported. For situations where the {data-store-name} cache needs to be configured natively,
you can provide a reference to the {data-store-name} XML configuration file by using the `cache-xml-location` attribute,
as follows:
[source,xml]
----
<gfe:cache id="cacheConfiguredWithNativeCacheXml" cache-xml-location="classpath:cache.xml"/>
----
In this example, if a cache needs to be created, it uses a file named `cache.xml` located in the classpath root
to configure it.
NOTE: The configuration makes use of Spring's https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#resources[`Resource`]
abstraction to locate the file. The `Resource` abstraction lets various search patterns be used, depending on the runtime environment
or the prefix specified (if any) in the resource location.
In addition to referencing an external XML configuration file, you can also specify {data-store-name} System
{x-data-store-docs}/reference/topics/gemfire_properties.html[properties] that use any of Spring's `Properties`
support features.
For example, you can use the `properties` element defined in the `util` namespace to define `Properties` directly
or load properties from a properties file, as follows:
[source,xml]
[subs="verbatim,attributes"]
----
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:gfe="{spring-data-schema-namespace}"
xmlns:util="http://www.springframework.org/schema/util"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
{spring-data-schema-namespace} {spring-data-schema-location}
http://www.springframework.org/schema/util https://www.springframework.org/schema/util/spring-util.xsd
">
<util:properties id="gemfireProperties" location="file:/path/to/gemfire.properties"/>
<gfe:cache properties-ref="gemfireProperties"/>
</beans>
----
Using a properties file is recommended for externalizing environment-specific settings
outside the application configuration.
NOTE: Cache settings apply only when a new cache needs to be created. If an open cache already exists in the VM,
these settings are ignored.
[[bootstrap:cache:advanced]]
== Advanced Cache Configuration
For advanced cache configuration, the `cache` element provides a number of configuration options exposed as attributes
or child elements, as the following listing shows:
[source,xml]
----
<!--1-->
<gfe:cache
cache-xml-location=".."
properties-ref=".."
close="false"
copy-on-read="true"
critical-heap-percentage="90"
eviction-heap-percentage="70"
enable-auto-reconnect="false" <!--2-->
lock-lease="120"
lock-timeout="60"
message-sync-interval="1"
pdx-serializer-ref="myPdxSerializer"
pdx-persistent="true"
pdx-disk-store="diskStore"
pdx-read-serialized="false"
pdx-ignore-unread-fields="true"
search-timeout="300"
use-bean-factory-locator="true" <!--3-->
use-cluster-configuration="false" <!--4-->
>
<gfe:transaction-listener ref="myTransactionListener"/> <!--5-->
<gfe:transaction-writer> <!--6-->
<bean class="org.example.app.gemfire.transaction.TransactionWriter"/>
</gfe:transaction-writer>
<gfe:gateway-conflict-resolver ref="myGatewayConflictResolver"/> <!--7-->
<gfe:jndi-binding jndi-name="myDataSource" type="ManagedDataSource"/> <!--8-->
</gfe:cache>
----
<1> Attributes support various cache options. For further information regarding anything shown in this example,
see the {data-store-name} https://docs.pivotal.io/gemfire[product documentation].
The `close` attribute determines whether the cache should be closed when the Spring application context is closed.
The default is `true`. However, for use cases in which multiple application contexts use the cache
(common in web applications), set this value to `false`.
<2> Setting the `enable-auto-reconnect` attribute to `true` (the default is `false`) lets a disconnected {data-store-name} member
automatically reconnect and rejoin the {data-store-name} cluster.
See the {data-store-name} {x-data-store-docs}/managing/autoreconnect/member-reconnect.html[product documentation]
for more details.
<3> Setting the `use-bean-factory-locator` attribute to `true` (it defaults to `false`) applies only when both
Spring (XML) configuration metadata and {data-store-name} `cache.xml` is used to configure the {data-store-name} cache node
(whether client or peer). This option lets {data-store-name} components (such as `CacheLoader`) expressed in `cache.xml`
be auto-wired with beans (such as `DataSource`) defined in the Spring application context. This option is typically
used in conjunction with `cache-xml-location`.
<4> Setting the `use-cluster-configuration` attribute to `true` (the default is `false`) enables a {data-store-name} member to
retrieve the common, shared Cluster-based configuration from a Locator.
See the {data-store-name} {x-data-store-docs}/configuring/cluster_config/gfsh_persist.html[product documentation]
for more details.
<5> Example of a `TransactionListener` callback declaration that uses a bean reference. The referenced bean must implement
{x-data-store-javadoc}/org/apache/geode/cache/TransactionListener.html[TransactionListener].
A `TransactionListener` can be implemented to handle transaction related events (such as afterCommit and afterRollback).
<6> Example of a `TransactionWriter` callback declaration using an inner bean declaration. The bean must implement
{x-data-store-javadoc}/org/apache/geode/cache/TransactionWriter.html[TransactionWriter].
The `TransactionWriter` is a callback that can veto a transaction.
<7> Example of a `GatewayConflictResolver` callback declaration using a bean reference. The referenced bean
must implement {x-data-store-javadoc}/org/apache/geode/cache/util/GatewayConflictResolver.html
[GatewayConflictResolver].
A `GatewayConflictResolver` is a `Cache`-level plugin that is called upon to decide what to do with events
that originate in other systems and arrive through the WAN Gateway.
which provides a distributed Region creation service.
<8> Declares a JNDI binding to enlist an external DataSource in a {data-store-name} transaction.
[[bootstrap:cache:pdx-serialization]]
=== Enabling PDX Serialization
The preceding example includes a number of attributes related to {data-store-name}'s enhanced serialization framework, PDX.
While a complete discussion of PDX is beyond the scope of this reference guide, it is important to note that PDX
is enabled by registering a `PdxSerializer`, which is specified by setting the `pdx-serializer` attribute.
{data-store-name} provides an implementing class (`org.apache.geode.pdx.ReflectionBasedAutoSerializer`) that uses
Java Reflection. However, it is common for developers to provide their own implementation. The value of the attribute
is simply a reference to a Spring bean that implements the `PdxSerializer` interface.
More information on serialization support can be found in <<serialization>>.
[[boostrap:cache:auto-reconnect]]
=== Enabling Auto-reconnect
You should be careful when setting the `<gfe:cache enable-auto-reconnect="[true|false*]>` attribute to `true`.
Generally, 'auto-reconnect' should only be enabled in cases where {sdg-name}'s XML namespace is used to configure
and bootstrap a new, non-application {data-store-name} server added to a cluster. In other words, 'auto-reconnect'
should not be enabled when {sdg-name} is used to develop and build a {data-store-name} application that also happens
to be a peer `Cache` member of the {data-store-name} cluster.
The main reason for this restriction is that most {data-store-name} applications use references to the {data-store-name}
`Cache` or Regions in order to perform data access operations. These references are "`injected`" by the Spring container
into application components (such as Repositories) for use by the application. When a peer member is forcefully
disconnected from the rest of the cluster, presumably because the peer member has become unresponsive or a
network partition separates one or more peer members into a group too small to function as an independent
distributed system, the peer member shuts down and all {data-store-name} component references (caches, Regions,
and others) become invalid.
Essentially, the current forced disconnect processing logic in each peer member dismantles the system from the ground up.
The JGroups stack shuts down, the distributed system is put in a shutdown state and, finally, the cache is closed.
Effectively, all memory references become stale and are lost.
After being disconnected from the distributed system, a peer member enters a "`reconnecting`" state and periodically
attempts to rejoin the distributed system. If the peer member succeeds in reconnecting, the member rebuilds its "`view`"
of the distributed system from existing members and receives a new distributed system ID. Additionally, all caches,
Regions, and other {data-store-name} components are reconstructed. Therefore, all old references, which may have been
injected into application by the Spring container, are now stale and no longer valid.
{data-store-name} makes no guarantee (even when using the {data-store-name} public Java API) that application cache,
Regions, or other component references are automatically refreshed by the reconnect operation. As such, {data-store-name}
applications must take care to refresh their own references.
Unfortunately, there is no way to be notified of a disconnect event and, subsequently, a reconnect event either.
If that were the case, you would have a clean way to know when to call `ConfigurableApplicationContext.refresh()`,
if it were even applicable for an application to do so, which is why this "`feature`" of {data-store-name} is not
recommended for peer `Cache` applications.
For more information about 'auto-reconnect', see {data-store-name}'s
{x-data-store-docs}/managing/autoreconnect/member-reconnect.html[product documentation].
[[bootstrap:cache:cluster-configuration]]
=== Using Cluster-based Configuration
{data-store-name}'s Cluster Configuration Service is a convenient way for any peer member joining the cluster to get
a "`consistent view`" of the cluster by using the shared, persistent configuration maintained by a Locator.
Using the cluster-based configuration ensures the peer member's configuration is compatible with the {data-store-name}
Distributed System when the member joins.
This feature of {sdg-name} (setting the `use-cluster-configuration` attribute to `true`) works in the same way
as the `cache-xml-location` attribute, except the source of the {data-store-name} configuration meta-data comes
from the network through a Locator, as opposed to a native `cache.xml` file residing in the local file system.
All {data-store-name} native configuration metadata, whether from `cache.xml` or from the Cluster Configuration Service,
gets applied before any Spring (XML) configuration metadata. As a result, Spring's config serves to "`augment`" the
native {data-store-name} configuration metadata and would most likely be specific to the application.
Again, to enable this feature, specify the following in the Spring XML config:
[source,xml]
----
<gfe:cache use-cluster-configuration="true"/>
----
NOTE: While certain {data-store-name} tools, such as _Gfsh_, have their actions "`recorded`" when schema-like changes
are made (for example, `gfsh>create region --name=Example --type=PARTITION`), {sdg-name}'s configuration metadata
is not recorded. The same is true when using {data-store-name}'s public Java API directly. It, too, is not recorded.
For more information on {data-store-name}'s Cluster Configuration Service, see the
{x-data-store-docs}/configuring/cluster_config/gfsh_persist.html[product documentation].
[[bootstrap:cache:server]]
== Configuring a {data-store-name} CacheServer
{sdg-name} includes dedicated support for configuring a
{x-data-store-javadoc}/org/apache/geode/cache/server/CacheServer.html[CacheServer],
allowing complete configuration through the Spring container, as the following example shows:
[source,xml]
[subs="verbatim,attributes"]
----
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:gfe="{spring-data-schema-namespace}"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context https://www.springframework.org/schema/context/spring-context.xsd
{spring-data-schema-namespace} {spring-data-schema-location}
">
<gfe:cache/>
<!-- Example depicting serveral {data-store-name} CacheServer configuration options -->
<gfe:cache-server id="advanced-config" auto-startup="true"
bind-address="localhost" host-name-for-clients="localhost" port="${gemfire.cache.server.port}"
load-poll-interval="2000" max-connections="22" max-message-count="1000" max-threads="16"
max-time-between-pings="30000" groups="test-server">
<gfe:subscription-config eviction-type="ENTRY" capacity="1000" disk-store="file://${java.io.tmpdir}"/>
</gfe:cache-server>
<context:property-placeholder location="classpath:cache-server.properties"/>
</beans>
----
The preceding configuration shows the `cache-server` element and the many available options.
NOTE: Rather than hard-coding the port, this configuration uses Spring's
https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#xsd-config-body-schemas-context[context]
namespace to declare a `property-placeholder`. A
https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-factory-placeholderconfigurer[property placeholder]
reads one or more properties files and then replaces property placeholders with values at runtime. Doing so lets administrators
change values without having to touch the main application configuration. Spring also provides
https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#expressions[SpEL]
and an https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-environment[environment abstraction]
to support externalization of environment-specific properties from the main codebase, easing deployment across multiple machines.
NOTE: To avoid initialization problems, the `CacheServer` started by {sdg-name} starts *after* the Spring container
has been fully initialized. Doing so lets potential Regions, listeners, writers or instantiators that are defined
declaratively to be fully initialized and registered before the server starts accepting connections. Keep this in mind
when programmatically configuring these elements, as the server might start before your components and thus not be seen
by the clients connecting right away.
[[bootstrap:cache:client]]
== Configuring a {data-store-name} ClientCache
In addition to defining a {data-store-name} peer {x-data-store-javadoc}/org/apache/geode/cache/Cache.html[`Cache`],
{sdg-name} also supports the definition of a {data-store-name} {x-data-store-javadoc}/org/apache/geode/cache/client/ClientCache.html[`ClientCache`]
in a Spring container. A `ClientCache` definition is similar in configuration and use to the {data-store-name} peer <<bootstrap:cache,Cache>>
and is supported by the `org.springframework.data.gemfire.client.ClientCacheFactoryBean`.
The simplest definition of a {data-store-name} cache client using default configuration follows:
[source,xml]
----
<beans>
<gfe:client-cache/>
</beans>
----
`client-cache` supports many of the same options as the <<bootstrap:cache:advanced,Cache>> element. However, as opposed
to a full-fledged peer `Cache` member, a cache client connects to a remote cache server through a Pool. By default,
a Pool is created to connect to a server running on `localhost` and listening to port `40404`. The default Pool is used
by all client Regions unless the Region is configured to use a specific Pool.
Pools can be defined with the `pool` element. This client-side Pool can be used to configure connectivity directly to
a server for individual entities or for the entire cache through one or more Locators.
For example, to customize the default Pool used by the `client-cache`, the developer needs to define a Pool and wire it
to the cache definition, as the following example shows:
[source,xml]
----
<beans>
<gfe:client-cache id="myCache" pool-name="myPool"/>
<gfe:pool id="myPool" subscription-enabled="true">
<gfe:locator host="${gemfire.locator.host}" port="${gemfire.locator.port}"/>
</gfe:pool>
</beans>
----
The `<client-cache>` element also has a `ready-for-events` attribute. If the attribute is set to `true`, the client cache
initialization includes a call to {x-data-store-javadoc}/org/apache/geode/cache/client/ClientCache.html#readyForEvents[`ClientCache.readyForEvents()`].
<<bootstrap:region:client>> covers client-side configuration in more detail.
[[bootstrap:cache:client:pool]]
=== {data-store-name}'s DEFAULT Pool and {sdg-name} Pool Definitions
If a {data-store-name} `ClientCache` is local-only, then no Pool definition is required. For instance, you can define
the following:
[source,xml]
----
<gfe:client-cache/>
<gfe:client-region id="Example" shortcut="LOCAL"/>
----
In this case, the "`Example`" Region is `LOCAL` and no data is distributed between the client and a server. Therefore,
no Pool is necessary. This is true for any client-side, local-only Region, as defined by the {data-store-name}'s
{x-data-store-javadoc}/org/apache/geode/cache/client/ClientRegionShortcut.html[`ClientRegionShortcut`]
(all `LOCAL_*` shortcuts).
However, if a client Region is a (caching) proxy to a server-side Region, a Pool is required. In that case,
there are several ways to define and use a Pool.
When a `ClientCache`, a Pool, and a proxy-based Region are all defined but not explicitly identified, {sdg-name}
resolves the references automatically, as the following example shows:
[source,xml]
----
<gfe:client-cache/>
<gfe:pool>
<gfe:locator host="${geode.locator.host}" port="${geode.locator.port}"/>
</gfe:pool>
<gfe:client-region id="Example" shortcut="PROXY"/>
----
In the preceding example, the `ClientCache` is identified as `gemfireCache`, the Pool as `gemfirePool`,
and the client Region as "`Example`". However, the `ClientCache` initializes {data-store-name}'s `DEFAULT` Pool
from `gemfirePool`, and the client Region uses the `gemfirePool` when distributing data between the client
and the server.
Basically, {sdg-name} resolves the preceding configuration to the following:
[source,xml]
----
<gfe:client-cache id="gemfireCache" pool-name="gemfirePool"/>
<gfe:pool id="gemfirePool">
<gfe:locator host="${geode.locator.host}" port="${geode.locator.port}"/>
</gfe:pool>
<gfe:client-region id="Example" cache-ref="gemfireCache" pool-name="gemfirePool" shortcut="PROXY"/>
----
{data-store-name} still creates a Pool called `DEFAULT`. {sdg-name} causes the `DEFAULT` Pool to be initialized
from the `gemfirePool`. Doing so is useful in situations where multiple Pools are defined and client Regions
are using separate Pools, or do not declare a Pool at all.
Consider the following:
[source,xml]
----
<gfe:client-cache pool-name="locatorPool"/>
<gfe:pool id="locatorPool">
<gfe:locator host="${geode.locator.host}" port="${geode.locator.port}"/>
</gfe:pool>
<gfe:pool id="serverPool">
<gfe:server host="${geode.server.host}" port="${geode.server.port}"/>
</gfe:pool>
<gfe:client-region id="Example" pool-name="serverPool" shortcut="PROXY"/>
<gfe:client-region id="AnotherExample" shortcut="CACHING_PROXY"/>
<gfe:client-region id="YetAnotherExample" shortcut="LOCAL"/>
----
In this setup, the {data-store-name} `client-cache` `DEFAULT` pool is initialized from `locatorPool`,
as specified by the `pool-name` attribute. There is no {sdg-name}-defined `gemfirePool`, since both Pools
were explicitly identified (named) -- `locatorPool` and `serverPool`, respectively.
The "`Example`" Region explicitly refers to and exclusively uses the `serverPool`. The `AnotherExample` Region uses
{data-store-name}'s `DEFAULT` Pool, which, again, was configured from the `locatorPool` based on the client cache
bean definition's `pool-name` attribute.
Finally, the `YetAnotherExample` Region does not use a Pool, because it is `LOCAL`.
NOTE: The `AnotherExample` Region would first look for a Pool bean named `gemfirePool`, but that would require
the definition of an anonymous Pool bean (that is, `<gfe:pool/>`) or a Pool bean explicitly named `gemfirePool`
(for example, `<gfe:pool id="gemfirePool"/>`).
NOTE: If we either changed the name of `locatorPool` to `gemfirePool` or made the Pool bean definition be anonymous,
it would have the same effect as the preceding configuration.

149
spring-data-geode-docs/src/docs/asciidoc/reference/cq-container.adoc Normal file
View File

@@ -0,0 +1,149 @@
[[apis:continuous-query]]
= Continuous Query (CQ)
A powerful functionality offered by {data-store-name} is
{x-data-store-docs}/developing/continuous_querying/chapter_overview.html[Continuous Query] (or CQ).
In short, CQ allows a developer to create and register an OQL query, and then automatically be notified when new data
that gets added to {data-store-name} matches the query predicate. {sdg-name} provides dedicated
support for CQs through the `org.springframework.data.gemfire.listener` package and its *listener container*;
very similar in functionality and naming to the JMS integration in the _Spring Framework_; in fact, users familiar with
the JMS support in Spring, should feel right at home.
Basically {sdg-name} allows methods on POJOs to become end-points for CQ. Simply define the query
and indicate the method that should be called to be notified when there is a match. {sdg-name} takes care
of the rest. This is very similar to Java EE's message-driven bean style, but without any requirement for base class
or interface implementations, based on {data-store-name}.
NOTE: Currently, Continuous Query is only supported in {data-store-name}'s client/server topology. Additionally, the client Pool
used is required to have the subscription enabled. Please refer to the {data-store-name}
{x-data-store-docs}/developing/continuous_querying/implementing_continuous_querying.html[documentation]
for more information.
[[apis:continuous-query:container]]
== Continuous Query Listener Container
{sdg-name} simplifies creation, registration, life-cycle and dispatch of CQ events by taking care of
the infrastructure around CQ with the use of SDG's `ContinuousQueryListenerContainer`, which does all the heavy lifting
on behalf of the user. Users familiar with EJB and JMS should find the concepts familiar as it is designed
as close as possible to the support provided in the _Spring Framework_ with its Message-driven POJOs (MDPs).
The SDG `ContinuousQueryListenerContainer` acts as an event (or message) listener container; it is used to
receive the events from the registered CQs and invoke the POJOs that are injected into it. The listener container
is responsible for all threading of message reception and dispatches into the listener for processing. It acts as
the intermediary between an EDP (Event-driven POJO) and the event provider and takes care of creation and registration
of CQs (to receive events), resource acquisition and release, exception conversion and the like. This allows you,
as an application developer, to write the (possibly complex) business logic associated with receiving an event
(and reacting to it), and delegate the boilerplate {data-store-name} infrastructure concerns to the framework.
The listener container is fully customizable. A developer can chose either to use the CQ thread to perform the dispatch
(synchronous delivery) or a new thread (from an existing pool) for an asynchronous approach by defining the suitable
`java.util.concurrent.Executor` (or Spring's `TaskExecutor`). Depending on the load, the number of listeners
or the runtime environment, the developer should change or tweak the executor to better serve her needs. In particular,
in managed environments (such as app servers), it is highly recommended to pick a proper `TaskExecutor`
to take advantage of its runtime.
[[apis:continuous-query:adapter]]
== The `ContinuousQueryListener` and `ContinuousQueryListenerAdapter`
The `ContinuousQueryListenerAdapter` class is the final component in {sdg-name} CQ support. In a nutshell,
class allows you to expose almost *any* implementing class as an EDP with minimal constraints.
`ContinuousQueryListenerAdapter` implements the `ContinuousQueryListener` interface, a simple listener interface
similar to {data-store-name}'s {x-data-store-javadoc}/org/apache/geode/cache/query/CqListener.html[CqListener].
Consider the following interface definition. Notice the various event handling methods and their parameters:
[source,java]
----
public interface EventDelegate {
void handleEvent(CqEvent event);
void handleEvent(Operation baseOp);
void handleEvent(Object key);
void handleEvent(Object key, Object newValue);
void handleEvent(Throwable throwable);
void handleQuery(CqQuery cq);
void handleEvent(CqEvent event, Operation baseOp, byte[] deltaValue);
void handleEvent(CqEvent event, Operation baseOp, Operation queryOp, Object key, Object newValue);
}
----
[source,java]
----
package example;
class DefaultEventDelegate implements EventDelegate {
// implementation elided for clarity...
}
----
In particular, note how the above implementation of the `EventDelegate` interface has *no* {data-store-name} dependencies at all.
It truly is a POJO that we can and will make into an EDP via the following configuration.
NOTE: the class does not have to implement an interface; an interface is only used to better showcase the decoupling
between the contract and the implementation.
[source,xml]
[subs="verbatim,attributes"]
----
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:gfe="{spring-data-schema-namespace}"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
{spring-data-schema-namespace} {spring-data-schema-location}
">
<gfe:client-cache/>
<gfe:pool subscription-enabled="true">
<gfe:server host="localhost" port="40404"/>
</gfe:pool>
<gfe:cq-listener-container>
<!-- default handle method -->
<gfe:listener ref="listener" query="SELECT * FROM /SomeRegion"/>
<gfe:listener ref="another-listener" query="SELECT * FROM /AnotherRegion" name="myQuery" method="handleQuery"/>
</gfe:cq-listener-container>
<bean id="listener" class="example.DefaultMessageDelegate"/>
<bean id="another-listener" class="example.DefaultMessageDelegate"/>
...
<beans>
----
NOTE: The example above shows a few of the various forms that a listener can have; at its minimum, the listener
reference and the actual query definition are required. It's possible, however, to specify a name for
the resulting Continuous Query (useful for monitoring) but also the name of the method (the default is `handleEvent`).
The specified method can have various argument types, the `EventDelegate` interface lists the allowed types.
The example above uses the {sdg-name} namespace to declare the event listener container
and automatically register the listeners. The full blown, *beans* definition is displayed below:
[source,xml]
----
<!-- this is the Event Driven POJO (MDP) -->
<bean id="eventListener" class="org.springframework.data.gemfire.listener.adapter.ContinuousQueryListenerAdapter">
<constructor-arg>
<bean class="gemfireexample.DefaultEventDelegate"/>
</constructor-arg>
</bean>
<!-- and this is the event listener container... -->
<bean id="gemfireListenerContainer" class="org.springframework.data.gemfire.listener.ContinuousQueryListenerContainer">
<property name="cache" ref="gemfireCache"/>
<property name="queryListeners">
<!-- set of CQ listeners -->
<set>
<bean class="org.springframework.data.gemfire.listener.ContinuousQueryDefinition" >
<constructor-arg value="SELECT * FROM /SomeRegion" />
<constructor-arg ref="eventListener"/>
</bean>
</set>
</property>
</bean>
----
Each time an event is received, the adapter automatically performs type translation between the {data-store-name} event
and the required method argument(s) transparently. Any exception caused by the method invocation is caught
and handled by the container (by default, being logged).

41
spring-data-geode-docs/src/docs/asciidoc/reference/data-access.adoc Normal file
View File

@@ -0,0 +1,41 @@
[[data-access]]
= Using the Data Access Namespace
In addition to the core XML namespace (`gfe`), {sdg-name} provides a data access XML namespace (`gfe-data`),
which is primarily intended to simplify the development of {data-store-name} client applications. This namespace
currently contains support for {data-store-name} <<gemfire-repositories, Repositories>> and Function
<<function-execution, execution>>, as well as a `<datasource>` tag that offers a convenient way to connect to
a {data-store-name} cluster.
[[data-access:datasource]]
== An Easy Way to Connect to {data-store-name}
For many applications, a basic connection to a {data-store-name} data grid using default values is sufficient.
{sdg-name}'s `<datasource>` tag provides a simple way to access data. The data source creates a `ClientCache`
and connection `Pool`. In addition, it queries the cluster servers for all existing root Regions and creates
an (empty) client Region proxy for each one.
[source,xml]
----
<gfe-data:datasource>
<locator host="remotehost" port="1234"/>
</gfe-data:datasource>
----
The `<datasource>` tag is syntactically similar to `<gfe:pool>`. It may be configured with one or more nested `locator`
or `server` elements to connect to an existing data grid. Additionally, all attributes available to configure a Pool
are supported. This configuration automatically creates client Region beans for each Region defined on cluster members
connected to the Locator, so they can be seamlessly referenced by Spring Data mapping annotations (`GemfireTemplate`)
and autowired into application classes.
Of course, you can explicitly configure client Regions. For example, if you want to cache data in local memory,
as the following example shows:
[source,xml]
----
<gfe-data:datasource>
<locator host="remotehost" port="1234"/>
</gfe-data:datasource>
<gfe:client-region id="Example" shortcut="CACHING_PROXY"/>
----

747
spring-data-geode-docs/src/docs/asciidoc/reference/data.adoc Normal file
View File

@@ -0,0 +1,747 @@
[[apis]]
= Working with {data-store-name} APIs
Once the {data-store-name} Cache and Regions have been configured, they can be injected and used inside application objects.
This chapter describes the integration with Spring's Transaction Management functionality and DAO exception hierarchy.
This chapter also covers support for dependency injection of {data-store-name} managed objects.
[[apis:template]]
== GemfireTemplate
As with many other high-level abstractions provided by Spring, {sdg-name} provides a *template*
to simplify {data-store-name} data access operations. The class provides several methods containing common Region operations,
but also provides the capability to *execute* code against native {data-store-name} APIs without having to deal with
{data-store-name} checked exceptions by using a `GemfireCallback`.
The template class requires a {data-store-name} `Region`, and once configured, is thread-safe and is reusable
across multiple application classes:
[source,xml]
----
<bean id="gemfireTemplate" class="org.springframework.data.gemfire.GemfireTemplate" p:region-ref="SomeRegion"/>
----
Once the template is configured, a developer can use it alongside `GemfireCallback` to work directly with
the {data-store-name} `Region` without having to deal with checked exceptions, threading or resource management concerns:
[source,java]
----
template.execute(new GemfireCallback<Iterable<String>>() {
public Iterable<String> doInGemfire(Region region)
throws GemFireCheckedException, GemFireException {
Region<String, String> localRegion = (Region<String, String>) region;
localRegion.put("1", "one");
localRegion.put("3", "three");
return localRegion.query("length < 5");
}
});
----
For accessing the full power of the {data-store-name} query language, a developer can use the `find` and `findUnique`
methods, which, compared to the `query` method, can execute queries across multiple Regions, execute projections,
and the like.
The `find` method should be used when the query selects multiple items (through `SelectResults`) and the latter,
`findUnique`, as the name suggests, when only one object is returned.
[[apis:exception-translation]]
== Exception Translation
Using a new data access technology requires not only accommodating a new API but also handling exceptions
specific to that technology.
To accommodate the exception handling case, the _Spring Framework_ provides a technology agnostic and consistent
https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#dao-exceptions[exception hierarchy]
that abstracts the application from proprietary, and usually "checked", exceptions to a set of focused runtime
exceptions.
As mentioned in _Spring Framework's_ documentation,
https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#orm-exception-translation[Exception translation]
can be applied transparently to your Data Access Objects (DAO) through the use of the `@Repository` annotation and AOP
by defining a `PersistenceExceptionTranslationPostProcessor` bean. The same exception translation functionality
is enabled when using {data-store-name} as long as the `CacheFactoryBean` is declared, e.g. using either a `<gfe:cache/>`
or `<gfe:client-cache>` declaration, which acts as an exception translator and is automatically detected by
the Spring infrastructure and used accordingly.
[[apis:transaction-management]]
== Local, Cache Transaction Management
One of the most popular features of the _Spring Framework_ is
https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#transaction[Transaction Management].
If you are not familiar with Spring's transaction abstraction then we strongly recommend
https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#transaction-motivation[reading]
about _Spring's Transaction Management_ infrastructure as it offers a consistent _programming model_ that works
transparently across multiple APIs and can be configured either programmatically or declaratively
(the most popular choice).
For {data-store-name}, {sdg-name} provides a dedicated, per-cache, `PlatformTransactionManager` that, once declared,
allows Region operations to be executed atomically through Spring:
.Enable Transaction Management using XML
[source,xml]
----
<gfe:transaction-manager id="txManager" cache-ref="myCache"/>
----
NOTE: The example above can be simplified even further by eliminating the `cache-ref` attribute if the {data-store-name}
cache is defined under the default name, `gemfireCache`. As with the other {sdg-name} namespace elements, if the cache
bean name is not configured, the aforementioned naming convention will be used. Additionally, the transaction manager
name is "`gemfireTransactionManager`" if not explicitly specified.
Currently, {data-store-name} supports optimistic transactions with *read committed* isolation. Furthermore, to guarantee
this isolation, developers should avoid making *in-place* changes that manually modify values present in the cache.
To prevent this from happening, the transaction manager configures the cache to use *copy on read* semantics by default,
meaning a clone of the actual value is created each time a read is performed. This behavior can be disabled if needed
through the `copyOnRead` property.
Since a copy of the value for a given key is made when *copy on read* is enabled, you must subsequently call
`Region.put(key, value)` inorder for the value to be updated, transactionally.
For more information on the semantics and behavior of the underlying Geode transaction manager, please refer to the Geode
{x-data-store-javadoc}/org/apache/geode/cache/CacheTransactionManager.html[CacheTransactionManager Javadoc]
as well as the {x-data-store-docs}/developing/transactions/chapter_overview.html[documentation].
[[apis:global-transaction-management]]
== Global, JTA Transaction Management
It is also possible for {data-store-name} to participate in Global, JTA-based transactions, such as a transaction
managed by an Java EE Application Server (e.g. WebSphere Application Server (WAS)) using Container Managed Transactions
(CMT) along with other JTA resources.
However, unlike many other JTA "compliant" resources (e.g. JMS Message Brokers like ActiveMQ), {data-store-name} is *not*
an XA compliant resource. Therefore, {data-store-name} must be positioned as the "_Last Resource_" in a JTA transaction
(_prepare phase_) since it does not implement the 2-phase commit protocol, or rather does not handle distributed
transactions.
Many managed environments capable of CMT maintain support for "_Last Resource_", non-XA compliant resources in JTA-based
transactions, though it is not actually required in the JTA spec. More information on what a non-XA compliant,
"_Last Resource_" means can be found in Red Hat's https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/5/html/Administration_And_Configuration_Guide/lrco-overview.html[documentation].
In fact, Red Hat's JBoss project, https://narayana.io/[Narayana] is one such LGPL Open Source implementation. _Narayana_
refers to this as "_Last Resource Commit Optimization_" (LRCO). More details can be found https://narayana.io//docs/project/index.html#d0e1859[here].
However, whether you are using {data-store-name} in a standalone environment with an Open Source JTA Transaction
Management implementation that supports "_Last Resource_", or a managed environment (e.g. Java EE AS such as WAS),
{sdg-name} has you covered.
There are a series of steps you must complete to properly use {data-store-name} as a "_Last Resource_" in a JTA
transaction involving more than 1 transactional resource. Additionally, there can only be 1 non-XA compliant resource
(e.g. {data-store-name}) in such an arrangement.
1) First, you must complete Steps 1-4 in {data-store-name}'s documentation
{apache-geode-docs}/developing/transactions/JTA_transactions.html#concept_csy_vfb_wk[here].
NOTE: #1 above is independent of your Spring [Boot] and/or [Data for {data-store-name}] application and must be
completed successfully.
2) Referring to Step 5 in {data-store-name}'s {apache-geode-docs}/developing/transactions/JTA_transactions.html#concept_csy_vfb_wk[documentation],
{sdg-name}'s Annotation support will attempt to set the `GemFireCache`, {x-data-store-javadoc}/org/apache/geode/cache/GemFireCache.html#setCopyOnRead-boolean-[`copyOnRead`]
property for you when using the `@EnableGemFireAsLastResource` annotation.
However, if SDG's auto-configuration is unsuccessful in this regard, then you must explicitly set the `copy-on-read`
attribute in the `<gfe:cache>` or `<gfe:client-cache>` XML element or set the `copyOnRead` property of
the `CacheFactoryBean` class in JavaConfig to *true*. For example:
`ClientCache` XML:
.Set copy-on-read using XML (client)
[source,xml]
----
<gfe:client-cache ... copy-on-read="true"/>
----
`ClientCache` _JavaConfig_:
.Set copyOnRead using JavaConfig (client)
[source,java]
----
@Bean
ClientCacheFactoryBean gemfireCache() {
ClientCacheFactoryBean gemfireCache = new ClientCacheFactoryBean();
gemfireCache.setCopyOnRead(true);
return gemfireCache;
}
----
Peer `Cache` XML:
.Set copy-on-read using XML (server)
[source,xml]
----
<gfe:cache ... copy-on-read="true"/>
----
Peer `Cache` _JavaConfig_:
.Set copyOnRead using JavaConfig (server)
[source,java]
----
@Bean
CacheFactoryBean gemfireCache() {
CacheFactoryBean gemfireCache = new CacheFactoryBean();
gemfireCache.setCopyOnRead(true);
return gemfireCache;
}
----
NOTE: Explicitly setting the `copy-on-read` attribute or the `copyOnRead` property is really not necessary. Enabling
transaction management takes case of copying on reads.
3) At this point, you *skip* Steps 6-8 in {data-store-name}'s {apache-geode-docs}/developing/transactions/JTA_transactions.html#concept_csy_vfb_wk[documentation]
and let _Spring Data Geode_ work its magic. All you need to do is annotate your Spring `@Configuration` class
with {sdg-name}'s *new* `@EnableGemFireAsLastResource` annotation and a combination of Spring's
{spring-framework-docs}/#transaction[Transaction Management] infrastructure and {sdg-name}'s
`@EnableGemFireAsLastResource` annotation configuration does the trick.
The configuration looks like this...
[source,java]
----
@Configuration
@EnableGemFireAsLastResource
@EnableTransactionManagement(order = 1)
class GeodeConfiguration {
...
}
----
The only requirements are...
3.1) The `@EnableGemFireAsLastResource` annotation must be declared on the same Spring `@Configuration` class
where Spring's `@EnableTransactionManagement` annotation is also specified.
3.2) The `order` attribute of the `@EnableTransactionManagement` annotation must be explicitly set to an integer value
that is not `Integer.MAX_VALUE` or `Integer.MIN_VALUE` (defaults to `Integer.MAX_VALUE`).
Of course, hopefully you are aware that you also need to configure Spring's `JtaTransactionManager`
when using JTA transactions like so..
[source,java]
----
@Bean
public JtaTransactionManager transactionManager(UserTransaction userTransaction) {
JtaTransactionManager transactionManager = new JtaTransactionManager();
transactionManager.setUserTransaction(userTransaction);
return transactionManager;
}
----
NOTE: The configuration in section <<apis:transaction-management>> does *not* apply here.
The use of {sdg-name}'s `GemfireTransactionManager` is applicable in "Local-only", Cache Transactions,
*not* "Global", JTA Transactions. Therefore, you do *not* configure the SDG `GemfireTransactionManager` in this case.
You configure Spring's `JtaTransactionManager` as shown above.
For more details on using _Spring's Transaction Management_ with JTA,
see {spring-framework-docs}/#transaction-application-server-integration[here].
Effectively, {sdg-name}'s `@EnableGemFireAsLastResource` annotation imports configuration containing 2 Aspect
bean definitions that handles the {data-store-name} `o.a.g.ra.GFConnectionFactory.getConnection()`
and `o.a.g.ra.GFConnection.close()` operations at the appropriate points during the transactional operation.
Specifically, the correct sequence of events follow:
1. `jtaTransation.begin()`
2. `GFConnectionFactory.getConnection()`
3. Call the application's `@Transactional` service method
4. Either `jtaTransaction.commit()` or `jtaTransaction.rollback()`
5. Finally, `GFConnection.close()`
This is consistent with how you, as the application developer, would code this manually if you had to use the JTA API
+ {data-store-name} API yourself, as shown in the
{data-store-name} {apache-geode-docs}/developing/transactions/jca_adapter_example.html#concept_swv_z2p_wk[example].
Thankfully, Spring does the heavy lifting for you and all you need to do after applying the appropriate configuration
(shown above) is:
.Declaring a service method as @Transactional
[source,java]
----
@Service
class MyTransactionalService {
@Transactional
public <Return-Type> someTransactionalServiceMethod() {
// perform business logic interacting with and accessing multiple JTA resources atomically
}
...
}
----
#1 & #4 above are appropriately handled for you by Spring's JTA based `PlatformTransactionManager` once the
`@Transactional` boundary is entered by your application (i.e. when the `MyTransactionService.someTransactionalServiceMethod()`
is called).
#2 & #3 are handled by {sdg-name}'s new Aspects enabled with the `@EnableGemFireAsLastResource` annotation.
#3 of course is the responsibility of your application.
Indeed, with the appropriate logging configured, you will see the correct sequence of events...
.Transaction Log Output
[source,xml]
----
2017-Jun-22 11:11:37 TRACE TransactionInterceptor - Getting transaction for [example.app.service.MessageService.send]
2017-Jun-22 11:11:37 TRACE GemFireAsLastResourceConnectionAcquiringAspect - Acquiring {data-store-name} Connection
from {data-store-name} JCA ResourceAdapter registered at [gfe/jca]
2017-Jun-22 11:11:37 TRACE MessageService - PRODUCER [ Message :
[{ @type = example.app.domain.Message, id= MSG0000000000, message = SENT }],
JSON : [{"id":"MSG0000000000","message":"SENT"}] ]
2017-Jun-22 11:11:37 TRACE TransactionInterceptor - Completing transaction for [example.app.service.MessageService.send]
2017-Jun-22 11:11:37 TRACE GemFireAsLastResourceConnectionClosingAspect - Closed {data-store-name} Connection @ [Reference [...]]
----
For more details on using {data-store-name} cache-level transactions, see <<apis:transaction-management,here>>.
For more details on using {data-store-name} in JTA transactions,
see https://gemfire90.docs.pivotal.io/geode/developing/transactions/JTA_transactions.html[here].
For more details on configuring {data-store-name} as a "_Last Resource_",
see https://gemfire90.docs.pivotal.io/geode/developing/transactions/JTA_transactions.html#concept_csy_vfb_wk[here].
[[apis:using-transactional-event-listener]]
== Using @TransactionalEventListener
When using transactions, it may be desirable to register a listener to perform certain actions before or after the
transaction commits, or after a rollback occurs.
{sdg-name} makes it easy to create listeners that will be invoked during specific phases of a transaction with the
`@TransactionalEventListener` annotation. Methods annotated with `@TransactionalEventListener` (as shown below) will be
notified of events published from transactional methods, during the specified `phase`.
.After Transaction Commit Event Listener
[source,java]
----
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void handleAfterCommit(MyEvent event) {
// do something after transaction is committed
}
----
Inorder for the above method to be invoked, you must publish an event from within your transaction, like below:
.Publishing a Transactional Event
[source,java]
----
@Service
class MyTransactionalService {
@Autowired
private final ApplicationEventPublisher applicationEventPublisher;
@Transactional
public <Return-Type> someTransactionalServiceMethod() {
// Perform business logic interacting with and accessing multiple transactional resources atomically, then...
applicationEventPublisher.publishEvent(new MyApplicationEvent(...));
}
...
}
----
The `@TransactionalEventListener` annotation allows you to specify the transaction `phase` in which the event handler
method will be invoked. Options include: `AFTER_COMMIT`, `AFTER_COMPLETION`, `AFTER_ROLLBACK`, and `BEFORE_COMMIT`.
If not specified, the `phase` defaults to `AFTER_COMMIT`. If you wish the listener to be called even when no transaction
is present, you may set `fallbackExecution` to `true`.
[[apis:auto-transaction-event-publishing]]
== Auto Transaction Event Publishing
As of {sdg-name} `Neumann/2.3`, it is now possible to enable auto transaction event publishing.
Using the `@EnableGemfireCacheTransactions` annotation, set the `enableAutoTransactionEventPublishing` attribute
to *true*. The default is *false*.
.Enable auto transaction event publishing
[source,java]
----
@EnableGemfireCacheTransactions(enableAutoTransactionEventPublishing = true)
class GeodeConfiguration { ... }
----
Then you can create `@TransactionalEventListener` annotated POJO methods to handle transaction events during either
the `AFTER_COMMIT` or `AFTER_ROLLBACK` transaction phases.
[source,java]
----
@Component
class TransactionEventListeners {
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void handleAfterCommit(TransactionApplicationEvent event) {
...
}
@TransactionalEventListener(phase = TransactionPhase.AFTER_ROLLBACK)
public void handleAfterRollback(TransactionApplicationEvent event) {
...
}
}
----
WARNING: Only `TransactionPhase.AFTER_COMMIT` and `TransactionPhase.AFTER_ROLLBACK` are supported.
`TransactionPhase.BEFORE_COMMIT` is not supported because 1) SDG adapts {data-store-name}'s `TransactionListener`
and `TransactionWriter` interfaces to implement auto transaction event publishing, and 2) when {data-store-name}'s
`TransactionWriter.beforeCommit(:TransactionEvent)` is called, it is already after the
`AbstractPlatformTransactionManager.triggerBeforeCommit(:TransactionStatus)` call where `@TranactionalEventListener`
annotated POJO methods are called during the transaction lifecycle.
With auto transaction event publishing, you do not need to explicitly call the
`applicationEventPublisher.publishEvent(..)` method inside your application `@Transactional` `@Service` methods.
However, if you still want to receive transaction events "_before commit_", then you must still call the
`applicationEventPublisher.publishEvent(..)` method within your application `@Transactional` `@Service` methods.
See the *note* above for more details.
:leveloffset: +1
include::{basedocdir}/reference/cq-container.adoc[]
:leveloffset: -1
[[apis:declarable]]
== Wiring `Declarable` Components
{data-store-name} XML configuration (usually referred to as `cache.xml`) allows *user* objects to be declared
as part of the configuration. Usually these objects are `CacheLoaders` or other pluggable callback components
supported by {data-store-name}. Using native {data-store-name} configuration, each user type declared through XML must implement
the `Declarable` interface, which allows arbitrary parameters to be passed to the declared class
through a `Properties` instance.
In this section, we describe how you can configure these pluggable components when defined in `cache.xml`
using Spring while keeping your Cache/Region configuration defined in `cache.xml`. This allows your
pluggable components to focus on the application logic and not the location or creation of `DataSources`
or other collaborators.
However, if you are starting a green field project, it is recommended that you configure Cache, Region,
and other pluggable {data-store-name} components directly in Spring. This avoids inheriting from the `Declarable` interface
or the base class presented in this section.
See the following sidebar for more information on this approach.
.Eliminate `Declarable` components
****
A developer can configure custom types entirely through Spring as mentioned in <<bootstrap:region>>.
That way, a developer does not have to implement the `Declarable` interface, and also benefits from
all the features of the Spring IoC container (not just dependency injection but also life-cycle
and instance management).
****
As an example of configuring a `Declarable` component using Spring, consider the following declaration
(taken from the `Declarable` {x-data-store-javadoc}/org/apache/geode/cache/Declarable.html[Javadoc]):
[source,xml]
----
<cache-loader>
<class-name>com.company.app.DBLoader</class-name>
<parameter name="URL">
<string>jdbc://12.34.56.78/mydb</string>
</parameter>
</cache-loader>
----
To simplify the task of parsing, converting the parameters and initializing the object, {sdg-name} offers
a base class (`WiringDeclarableSupport`) that allows {data-store-name} user objects to be wired through a *template* bean definition
or, in case that is missing, perform auto-wiring through the Spring IoC container. To take advantage of this feature,
the user objects need to extend `WiringDeclarableSupport`, which automatically locates the declaring `BeanFactory`
and performs wiring as part of the initialization process.
.Why is a base class needed?
****
In the current {data-store-name} release there is no concept of an *object factory* and the types declared are instantiated
and used as is. In other words, there is no easy way to manage object creation outside {data-store-name}.
****
[[apis:declarable:template-wiring]]
=== Configuration using *template* bean definitions
When used, `WiringDeclarableSupport` tries to first locate an existing bean definition and use that
as the wiring template. Unless specified, the component class name will be used as an implicit bean definition name.
Let's see how our `DBLoader` declaration would look in that case:
[source,java]
----
class DBLoader extends WiringDeclarableSupport implements CacheLoader {
private DataSource dataSource;
public void setDataSource(DataSource dataSource){
this.dataSource = dataSource;
}
public Object load(LoaderHelper helper) { ... }
}
----
[source,xml]
----
<cache-loader>
<class-name>com.company.app.DBLoader</class-name>
<!-- no parameter is passed (use the bean's implicit name, which is the class name) -->
</cache-loader>
----
[source,xml]
----
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:p="http://www.springframework.org/schema/p"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
">
<bean id="dataSource" ... />
<!-- template bean definition -->
<bean id="com.company.app.DBLoader" abstract="true" p:dataSource-ref="dataSource"/>
</beans>
----
In the scenario above, as no parameter was specified, a bean with the id/name `com.company.app.DBLoader` was used
as a template for wiring the instance created by {data-store-name}. For cases where the bean name uses a different convention,
one can pass in the `bean-name` parameter in the {data-store-name} configuration:
[source,xml]
----
<cache-loader>
<class-name>com.company.app.DBLoader</class-name>
<!-- pass the bean definition template name as parameter -->
<parameter name="bean-name">
<string>template-bean</string>
</parameter>
</cache-loader>
----
[source,xml]
----
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:p="http://www.springframework.org/schema/p"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
">
<bean id="dataSource" ... />
<!-- template bean definition -->
<bean id="template-bean" abstract="true" p:dataSource-ref="dataSource"/>
</beans>
----
NOTE: The *template* bean definitions do not have to be declared in XML.
Any format is allowed (Groovy, annotations, etc).
[[apis:declarable:autowiring]]
=== Configuration using auto-wiring and annotations
By default, if no bean definition is found, `WiringDeclarableSupport` will
https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-factory-autowire[autowire]
the declaring instance. This means that unless any dependency injection *metadata* is offered by the instance,
the container will find the object setters and try to automatically satisfy these dependencies.
However, a developer can also use JDK 5 annotations to provide additional information to the auto-wiring process.
TIP: We strongly recommend reading the dedicated
https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-annotation-config[chapter]
in the Spring documentation for more information on the supported annotations and enabling factors.
For example, the hypothetical `DBLoader` declaration above can be injected with a Spring-configured `DataSource`
in the following way:
[source,java]
----
class DBLoader extends WiringDeclarableSupport implements CacheLoader {
// use annotations to 'mark' the needed dependencies
@javax.inject.Inject
private DataSource dataSource;
public Object load(LoaderHelper helper) { ... }
}
----
[source,xml]
----
<cache-loader>
<class-name>com.company.app.DBLoader</class-name>
<!-- no need to declare any parameters since the class is auto-wired -->
</cache-loader>
----
[source,xml]
----
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context https://www.springframework.org/schema/context/spring-context.xsd
">
<!-- enable annotation processing -->
<context:annotation-config/>
</beans>
----
By using the JSR-330 annotations, the `CacheLoader` code has been simplified since the location and creation
of the `DataSource` has been externalized and the user code is concerned only with the loading process.
The `DataSource` might be transactional, created lazily, shared between multiple objects or retrieved from JNDI.
These aspects can easily be configured and changed through the Spring container without touching
the `DBLoader` code.
[[apis:spring-cache-abstraction]]
== Support for the Spring Cache Abstraction
{sdg-name} provides an implementation of the Spring
https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#cache[Cache Abstraction]
to position {data-store-name} as a _caching provider_ in Spring's caching infrastructure.
To use {data-store-name} as a backing implementation, a "_caching provider_" _in Spring's Cache Abstraction_,
simply add `GemfireCacheManager` to your configuration:
[source,xml]
[subs="verbatim,attributes"]
----
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:cache="http://www.springframework.org/schema/cache"
xmlns:gfe="{spring-data-schema-namespace}"
xmlns:p="http://www.springframework.org/schema/p"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/cache https://www.springframework.org/schema/cache/spring-cache.xsd
{spring-data-schema-namespace} {spring-data-schema-location}
">
<!-- enable declarative caching -->
<cache:annotation-driven/>
<gfe:cache id="gemfire-cache"/>
<!-- declare GemfireCacheManager; must have a bean ID of 'cacheManager' -->
<bean id="cacheManager" class="org.springframework.data.gemfire.cache.GemfireCacheManager"
p:cache-ref="gemfire-cache">
</beans>
----
NOTE: The `cache-ref` attribute on the `CacheManager` bean definition is not necessary if the default cache bean name
is used (i.e. "gemfireCache"), i.e. `<gfe:cache>` without an explicit ID.
When the `GemfireCacheManager` (Singleton) bean instance is declared and declarative caching is enabled
(either in XML with `<cache:annotation-driven/>` or in JavaConfig with Spring's `@EnableCaching` annotation),
the Spring caching annotations (e.g. `@Cacheable`) identify the "caches" that will cache data in-memory
using {data-store-name} Regions.
These caches (i.e. Regions) must exist before the caching annotations that use them otherwise an error will occur.
By way of example, suppose you have a Customer Service application with a `CustomerService` application component
that performs caching...
[source,java]
----
@Service
class CustomerService {
@Cacheable(cacheNames="Accounts", key="#customer.id")
Account createAccount(Customer customer) {
...
}
----
Then you will need the following config.
XML:
[source,xml]
[subs="verbatim,attributes"]
----
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:cache="http://www.springframework.org/schema/cache"
xmlns:gfe="{spring-data-schema-namespace}"
xmlns:p="http://www.springframework.org/schema/p"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/cache https://www.springframework.org/schema/cache/spring-cache.xsd
{spring-data-schema-namespace} {spring-data-schema-location}
">
<!-- enable declarative caching -->
<cache:annotation-driven/>
<bean id="cacheManager" class="org.springframework.data.gemfire.cache.GemfireCacheManager">
<gfe:cache/>
<gfe:partitioned-region id="accountsRegion" name="Accounts" persistent="true" ...>
...
</gfe:partitioned-region>
</beans>
----
JavaConfig:
[source,java]
----
@Configuration
@EnableCaching
class ApplicationConfiguration {
@Bean
CacheFactoryBean gemfireCache() {
return new CacheFactoryBean();
}
@Bean
GemfireCacheManager cacheManager() {
GemfireCacheManager cacheManager = GemfireCacheManager();
cacheManager.setCache(gemfireCache());
return cacheManager;
}
@Bean("Accounts")
PartitionedRegionFactoryBean accountsRegion() {
PartitionedRegionFactoryBean accounts = new PartitionedRegionFactoryBean();
accounts.setCache(gemfireCache());
accounts.setClose(false);
accounts.setPersistent(true);
return accounts;
}
}
----
Of course, you are free to choose whatever Region type you like (e.g. REPLICATE, PARTITION, LOCAL, etc).
For more details on _Spring's Cache Abstraction_, again, please refer to the
https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#cache[documentation].

23
spring-data-geode-docs/src/docs/asciidoc/reference/diskstore.adoc Normal file
View File

@@ -0,0 +1,23 @@
[[bootstrap:diskstore]]
= Configuring a DiskStore
{sdg-name} supports `DiskStore` configuration and creation through the `disk-store` element,
as the following example shows:
[source,xml]
----
<gfe:disk-store id="Example" auto-compact="true" max-oplog-size="10"
queue-size="50" time-interval="9999">
<gfe:disk-dir location="/disk/location/one" max-size="20"/>
<gfe:disk-dir location="/disk/location/two" max-size="20"/>
</gfe:disk-store>
----
`DiskStore` instances are used by Regions for file system persistent backup and overflow of evicted entries
as well as persistent backup for WAN Gateways. Multiple {data-store-name} components may share the same `DiskStore`.
Additionally, multiple file system directories may be defined for a single `DiskStore`, as shown in
the preceding example.
See {data-store-name}'s documentation for a complete explanation of
{x-data-store-docs}/developing/storing_data_on_disk/chapter_overview.html[Persistence and Overflow]
and configuration options on `DiskStore` instances.

466
spring-data-geode-docs/src/docs/asciidoc/reference/function-annotations.adoc Normal file
View File

@@ -0,0 +1,466 @@
[[function-annotations]]
= Annotation Support for Function Execution
{sdg-name} includes annotation support to simplify working with {data-store-name}
{x-data-store-docs}/developing/function_exec/chapter_overview.html[Function execution].
Under the hood, the {data-store-name} API provides classes to implement and register {data-store-name}
{x-data-store-javadoc}/org/apache/geode/cache/execute/Function.html[Functions] that are deployed on {data-store-name}
servers, which may then be invoked by other peer member applications or remotely from cache clients.
Functions can execute in parallel, distributed among multiple {data-store-name} servers in the cluster, aggregating the
results using the map-reduce pattern and sent back to the caller. Functions can also be targeted to run on a single
server or Region. The {data-store-name} API supports remote execution of Functions targeted by using various predefined
scopes: on Region, on members (in groups), on servers, and others. The implementation and execution of remote Functions,
as with any RPC protocol, requires some boilerplate code.
{sdg-name}, true to Spring's core value proposition, aims to hide the mechanics of remote Function execution and let you
focus on core POJO programming and business logic. To this end, {sdg-name} introduces annotations to declaratively
register the public methods of a POJO class as {data-store-name} Functions along with the ability to invoke registered
Functions (including remotely) by using annotated interfaces.
[[function-implementation-execution]]
== Implementation Versus Execution
There are two separate concerns to address: implementation and execution.
The first is Function implementation (server-side), which must interact with the
{x-data-store-javadoc}/org/apache/geode/cache/execute/FunctionContext.html[`FunctionContext`]
to access the invocation arguments,
{x-data-store-javadoc}/org/apache/geode/cache/execute/ResultSender.html[`ResultsSender`] to send results,
and other execution context information. The Function implementation typically accesses the cache and Regions
and is registered with the
{x-data-store-javadoc}/org/apache/geode/cache/execute/FunctionService.html[`FunctionService`] under a unique ID.
A cache client application invoking a Function does not depend on the implementation. To invoke a Function,
the application instantiates an
{x-data-store-javadoc}/org/apache/geode/cache/execute/Execution.html[`Execution`]
providing the Function ID, invocation arguments, and the Function target, which defines its scope:
Region, server, servers, member, or members. If the Function produces a result, the invoker uses a
{x-data-store-javadoc}/org/apache/geode/cache/execute/ResultCollector.html[`ResultCollector`]
to aggregate and acquire the execution results. In certain cases, a custom `ResultCollector` implementation
is required and may be registered with the `Execution`.
NOTE: 'Client' and 'Server' are used here in the context of Function execution, which may have a different meaning
than client and server in {data-store-name}'s client-server topology. While it is common for an application using
a `ClientCache` instance to invoke a Function on one or more {data-store-name} servers in a cluster, it is also
possible to execute Functions in a peer-to-peer (P2P) configuration, where the application is a member of the cluster
hosting a peer `Cache` instance. Keep in mind that a peer member cache application is subject to all the constraints
of being a peer member of the cluster.
[[function-implementation]]
== Implementing a Function
Using {data-store-name} APIs, the `FunctionContext` provides a runtime invocation context that includes the client's
calling arguments and a `ResultSender` implementation to send results back to the client. Additionally, if the Function
is executed on a Region, the `FunctionContext` is actually an instance of `RegionFunctionContext`, which provides
additional information, such as the target Region on which the Function was invoked, any filter (a set of specific keys)
associated with the `Execution`, and so on. If the Region is a `PARTITION` Region, the Function should use
the `PartitionRegionHelper` to extract the local data set.
By using Spring, you can write a simple POJO and use the Spring container to bind one or more of your POJO's
public methods to a Function. The signature for a POJO method intended to be used as a Function must generally conform
to the client's execution arguments. However, in the case of a Region execution, the Region data may also be provided
(presumably the data is held in the local partition if the Region is a `PARTITION` Region).
Additionally, the Function may require the filter that was applied, if any. This suggests that the client and server
share a contract for the calling arguments but that the method signature may include additional parameters to pass values
provided by the `FunctionContext`. One possibility is for the client and server to share a common interface, but this
is not strictly required. The only constraint is that the method signature includes the same sequence of calling arguments
with which the Function was invoked after the additional parameters are resolved.
For example, suppose the client provides a `String` and an `int` as the calling arguments. These are provided
in the `FunctionContext` as an array, as the following example shows:
`Object[] args = new Object[] { "test", 123 };`
The Spring container should be able to bind to any method signature similar to the following (ignoring the return type
for the moment):
[source,java]
----
public Object method1(String s1, int i2) { ... }
public Object method2(Map<?, ?> data, String s1, int i2) { ... }
public Object method3(String s1, Map<?, ?> data, int i2) { ... }
public Object method4(String s1, Map<?, ?> data, Set<?> filter, int i2) { ... }
public void method4(String s1, Set<?> filter, int i2, Region<?,?> data) { ... }
public void method5(String s1, ResultSender rs, int i2) { ... }
public void method6(FunctionContest context) { ... }
----
The general rule is that once any additional arguments (that is, Region data and filter) are resolved,
the remaining arguments must correspond exactly, in order and type, to the expected Function method parameters.
The method's return type must be void or a type that may be serialized (as a `java.io.Serializable`, `DataSerializable`,
or `PdxSerializable`). The latter is also a requirement for the calling arguments.
The Region data should normally be defined as a `Map`, to facilitate unit testing, but may also be of type Region,
if necessary. As shown in the preceding example, it is also valid to pass the `FunctionContext` itself
or the `ResultSender` if you need to control over how the results are returned to the client.
[[function-implementation-annotations]]
=== Annotations for Function Implementation
The following example shows how {sdg-acronym}'s Function annotations are used to expose POJO methods
as {data-store-name} Functions:
[source,java]
----
@Component
public class ApplicationFunctions {
@GemfireFunction
public String function1(String value, @RegionData Map<?, ?> data, int i2) { ... }
@GemfireFunction(id = "myFunction", batchSize=100, HA=true, optimizedForWrite=true)
public List<String> function2(String value, @RegionData Map<?, ?> data, int i2, @Filter Set<?> keys) { ... }
@GemfireFunction(hasResult=true)
public void functionWithContext(FunctionContext functionContext) { ... }
}
----
Note that the class itself must be registered as a Spring bean and each {data-store-name} Function is annotated with
`@GemfireFunction`. In the preceding example, Spring's `@Component` annotation was used, but you can register the bean
by using any method supported by Spring (such as XML configuration or with a Java configuration class when using
Spring Boot). This lets the Spring container create an instance of this class and wrap it in a
https://docs.spring.io/spring-data-gemfire/docs/current/api/org/springframework/data/gemfire/function/PojoFunctionWrapper.html[`PojoFunctionWrapper`].
Spring creates a wrapper instance for each method annotated with `@GemfireFunction`. Each wrapper instance shares
the same target object instance to invoke the corresponding method.
TIP: The fact that the POJO Function class is a Spring bean may offer other benefits. Since it shares
the `ApplicationContext` with {data-store-name} components, such as the cache and Regions, these may be injected into
the class if necessary.
Spring creates the wrapper class and registers the Functions with {data-store-name}'s `FunctionService`. The Function ID
used to register each Function must be unique. By using convention, it defaults to the simple (unqualified) method name.
The name can be explicitly defined by using the `id` attribute of the `@GemfireFunction` annotation.
The `@GemfireFunction` annotation also provides other configuration attributes: `HA` and `optimizedForWrite`,
which correspond to properties defined by {data-store-name}'s
{x-data-store-javadoc}/org/apache/geode/cache/execute/Function.html[`Function`] interface.
If the POJO Function method's return type is `void`, then the `hasResult` attribute is automatically set to `false`.
Otherwise, if the method returns a value, the `hasResult` attributes is set to `true`. Even for `void` method return
types, the `GemfireFunction` annotation's `hasResult` attribute can be set to `true` to override this convention,
as shown in the `functionWithContext` method shown previously. Presumably, the intention is that you will use
the `ResultSender` directly to send results to the caller.
Finally, the `GemfireFunction` annotation supports the `requiredPermissions` attribute, which specifies the permissions
required to execute the Function. By default, all Functions require the `DATA:WRITE` permission. The attribute
accepts an array of Strings allowing you to modify the permissions as required by your application and/or Function UC.
Each resource permission is expected to be in the following format: `<RESOURCE>:<OPERATION>:[Target]:[Key]`.
`RESOURCE` can be 1 of the {data-store-javadoc]/org/apache/geode/security/ResourcePermission.Resource.html[`ResourcePermission.Resource`]
enumerated values. `OPERATION` can be 1 of the {data-store-javadoc}/org/apache/geode/security/ResourcePermission.Operation.html[`ResourcePermission.Operation`]
enumerated values. Optionally, `Target` can be the name of a Region or 1 of the
{data-store-javadoc}/org/apache/geode/security/ResourcePermission.Target.html[`ResourcePermission.Target`]
enumerated values. And finally, optionally, `Key` is a valid Key in the `Target` Region if specified.
The `PojoFunctionWrapper` implements {data-store-name}'s `Function` interface, binds method parameters, and invokes
the target method in its `execute()` method. It also sends the method's return value back to the caller
by using the `ResultSender`.
[[function-implementation-batching-results]]
=== Batching Results
If the return type is an array or `Collection`, then some consideration must be given to how the results are returned.
By default, the `PojoFunctionWrapper` returns the entire array or `Collection` at once. If the number of elements
in the array or `Collection` is quite large, it may incur a performance penalty. To divide the payload into smaller,
more manageable chunks, you can set the `batchSize` attribute, as illustrated in `function2`, shown earlier.
TIP: If you need more control of the `ResultSender`, especially if the method itself would use too much memory
to create the `Collection`, you can pass in the `ResultSender` or access it through the `FunctionContext`
and use it directly within the method to sends results back to the caller.
[[function-implementation-annotations-enabling]]
=== Enabling Annotation Processing
In accordance with Spring standards, you must explicitly activate annotation processing for `@GemfireFunction`
annotations. The following example activates annotation processing with XML:
[source,xml]
----
<gfe:annotation-driven/>
----
The following example activates annotation processing by annotating a Java configuration class:
[source,java]
----
@Configuration
@EnableGemfireFunctions
class ApplicationConfiguration { ... }
----
[[function-execution]]
== Executing a Function
A process that invokes a remote Function needs to provide the Function's ID, calling arguments, the execution target
(`onRegion`, `onServers`, `onServer`, `onMember`, or `onMembers`) and (optionally) a filter set. By using {sdg-name},
all you need do is define an interface supported by annotations. Spring creates a dynamic proxy for the interface,
which uses the `FunctionService` to create an `Execution`, invoke the `Execution`, and (if necessary) coerce
the results to the defined return type. This technique is similar to the way {sdg-name}'s Repository extension works.
Thus, some of the configuration and concepts should be familiar.
Generally, a single interface definition maps to multiple Function executions, one corresponding to each method
defined in the interface.
[[function-execution-annotations]]
=== Annotations for Function Execution
To support client-side Function execution, the following {sdg-acronym} Function annotations are provided: `@OnRegion`,
`@OnServer`, `@OnServers`, `@OnMember`, and `@OnMembers`. These annotations correspond to the `Execution`
implementations provided by {data-store-name}'s
{x-data-store-javadoc}/org/apache/geode/cache/execute/FunctionService.html[`FunctionService`] class.
Each annotation exposes the appropriate attributes. These annotations also provide an optional `resultCollector` attribute
whose value is the name of a Spring bean implementing the
{x-data-store-javadoc}/org/apache/geode/cache/execute/ResultCollector.html[`ResultCollector`] interface
to use for the execution.
CAUTION: The proxy interface binds all declared methods to the same execution configuration. Although it is expected
that single method interfaces are common, all methods in the interface are backed by the same proxy instance
and therefore all share the same configuration.
The following listing shows a few examples:
[source,java]
----
@OnRegion(region="SomeRegion", resultCollector="myCollector")
public interface FunctionExecution {
@FunctionId("function1")
String doIt(String s1, int i2);
String getString(Object arg1, @Filter Set<Object> keys);
}
----
By default, the Function ID is the simple (unqualified) method name. The `@FunctionId` annotation can be used
to bind this invocation to a different Function ID.
[[function-execution-annotations-enabling]]
=== Enabling Annotation Processing
The client-side uses Spring's classpath component scanning capability to discover annotated interfaces. To enable
Function execution annotation processing in XML, insert the following element in your XML configuration:
[source,xml]
----
<gfe-data:function-executions base-package="org.example.myapp.gemfire.functions"/>
----
The `function-executions` element is provided in the `gfe-data` XML namespace. The `base-package` attribute is required
to avoid scanning the entire classpath. Additional filters can be provided as described in the Spring
https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-scanning-filters[reference documentation].
Optionally, you can annotate your Java configuration class as follows:
[source,java]
----
@EnableGemfireFunctionExecutions(basePackages = "org.example.myapp.gemfire.functions")
----
[[function-execution-programmatic]]
== Programmatic Function Execution
Using the Function execution annotated interface defined in the previous section, simply auto-wire your interface
into an application bean that will invoke the Function:
[source,java]
----
@Component
public class MyApplication {
@Autowired
FunctionExecution functionExecution;
public void doSomething() {
functionExecution.doIt("hello", 123);
}
}
----
Alternately, you can use a Function execution template directly. In the following example,
the `GemfireOnRegionFunctionTemplate` creates an `onRegion` Function `Execution`:
.Using the `GemfireOnRegionFunctionTemplate`
====
[source,java]
----
Set<?, ?> myFilter = getFilter();
Region<?, ?> myRegion = getRegion();
GemfireOnRegionOperations template = new GemfireOnRegionFunctionTemplate(myRegion);
String result = template.executeAndExtract("someFunction", myFilter, "hello", "world", 1234);
----
====
Internally, Function `Executions` always return a `List`. `executeAndExtract` assumes a singleton `List`
containing the result and attempts to coerce that value into the requested type. There is also an `execute` method
that returns the `List` as is. The first parameter is the Function ID. The filter argument is optional. The remaining
arguments are a variable argument `List`.
[[function-execution-pdx]]
== Function Execution with PDX
When using {sdg-name}'s Function annotation support combined with {data-store-name}'s
{x-data-store-docs}/developing/data_serialization/gemfire_pdx_serialization.html[PDX Serialization],
there are a few logistical things to keep in mind.
As explained earlier in this section, and by way of example, you should typically define {data-store-name} Functions
by using POJO classes annotated with {sdg-name}
https://docs.spring.io/spring-data-gemfire/docs/current/api/org/springframework/data/gemfire/function/annotation/package-summary.html[Function annotations],
as follows:
[source,java]
----
public class OrderFunctions {
@GemfireFunction(...)
Order process(@RegionData data, Order order, OrderSource orderSourceEnum, Integer count) { ... }
}
----
NOTE: The `Integer` typed `count` parameter is arbitrary, as is the separation of the `Order` class
and the `OrderSource` enum, which might be logical to combine. However, the arguments were setup this way
to demonstrate the problem with Function executions in the context of PDX.
Your `Order` class and `OrderSource` enum might be defined as follows:
[source,java]
----
public class Order ... {
private Long orderNumber;
private LocalDateTime orderDateTime;
private Customer customer;
private List<Item> items
...
}
public enum OrderSource {
ONLINE,
PHONE,
POINT_OF_SALE
...
}
----
Of course, you can define a Function `Execution` interface to call the 'process' {data-store-name} server Function,
as follows:
[source,java]
----
@OnServer
public interface OrderProcessingFunctions {
Order process(Order order, OrderSource orderSourceEnum, Integer count);
}
----
Clearly, this `process(..)` `Order` Function is being called from the client-side with a `ClientCache` instance
(that is `<gfe:client-cache/>`). This implies that the Function arguments must also be serializable. The same is true
when invoking peer-to-peer member Functions (such as `@OnMember(s)`) between peers in the cluster. Any form of
`distribution` requires the data transmitted between client and server (or peers) to be serialized.
Now, if you have configured {data-store-name} to use PDX for serialization (instead of Java serialization, for instance)
you can also set the `pdx-read-serialized` attribute to `true` in your configuration of the {data-store-name} server(s),
as follows:
[source,xml]
----
<gfe:cache pdx-read-serialized="true"/>
----
Alternatively, you can set the `pdx-read-serialized` attribute to `true` for a {data-store-name} cache client application,
as follows:
[source,xml]
----
<gfe:client-cache pdx-read-serialized="true"/>
----
Doing so causes all values read from the cache (that is, Regions) as well as information passed between client and servers
(or peers) to remain in serialized form, including, but not limited to, Function arguments.
{data-store-name} serializes only application domain object types that you have specifically configured (registered)
either by using {data-store-name}'s
{x-data-store-javadoc}/org/apache/geode/pdx/ReflectionBasedAutoSerializer.html[`ReflectionBasedAutoSerializer`],
or specifically (and recommended) by using a "`custom`" {data-store-name}
{x-data-store-javadoc}/org/apache/geode/pdx/PdxSerializer.html[`PdxSerializer`].
If you use {sdg-name}'s Repository extension, you might even want to consider using {sdg-name}'s
{sdg-javadoc}/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html[`MappingPdxSerializer`],
which uses an entity's mapping metadata to determine data from the application domain object that is serialized
to the PDX instance.
What is less than apparent, though, is that {data-store-name} automatically handles Java `Enum` types regardless
of whether they are explicitly configured (that is, registered with a `ReflectionBasedAutoSerializer`,
using a regex pattern and the `classes` parameter or are handled by a "`custom`" {data-store-name} `PdxSerializer`),
despite the fact that Java enumerations implement `java.io.Serializable`.
So, when you set `pdx-read-serialized` to `true` on {data-store-name} servers where the {data-store-name} Functions
(including {sdg-name} Function-annotated POJO classes) are registered, then you may encounter surprising behavior
when invoking the Function `Execution`.
You might pass the following arguments when invoking the Function:
[source,java]
----
orderProcessingFunctions.process(new Order(123, customer, LocalDateTime.now(), items), OrderSource.ONLINE, 400);
----
However, the {data-store-name} Function on the server gets the following:
[source,java]
----
process(regionData, order:PdxInstance, :PdxInstanceEnum, 400);
----
The `Order` and `OrderSource` have been passed to the Function as
{x-data-store-javadoc}/org/apache/geode/pdx/PdxInstance.html[PDX instances].
Again, this all happens because `pdx-read-serialized` is set to `true`, which may be necessary in cases where
the {data-store-name} servers interact with multiple different clients (for example, a combination of Java clients
and native clients, such as C/C++, C#, and others).
This flies in the face of {sdg-name}'s strongly-typed Function-annotated POJO class method signatures, where you would
reasonably expect application domain object types instead, not PDX serialized instances.
Consequently, {sdg-name} includes enhanced Function support to automatically convert PDX typed method arguments
to the desired application domain object types defined by the Function method's signature (parameter types).
However, this also requires you to explicitly register a {data-store-name} `PdxSerializer` on {data-store-name} servers
where {sdg-name} Function-annotated POJOs are registered and used, as the following example shows:
[source,xml]
----
<bean id="customPdxSerializer" class="x.y.z.gemfire.serialization.pdx.MyCustomPdxSerializer"/>
<gfe:cache pdx-serializer-ref="customPdxSerializeer" pdx-read-serialized="true"/>
----
Alternatively, you can use {data-store-name}'s
{x-data-store-javadoc}/org/apache/geode/pdx/ReflectionBasedAutoSerializer.html[`ReflectionBasedAutoSerializer`]
for convenience. Of course, we recommend that, where possible, you use a custom `PdxSerializer` to maintain
finer-grained control over your serialization strategy.
Finally, {sdg-name} is careful not to convert your Function arguments if you treat your Function arguments generically
or as one of {data-store-name}'s PDX types, as follows:
[source,java]
----
@GemfireFunction
public Object genericFunction(String value, Object domainObject, PdxInstanceEnum pdxEnum) {
// ...
}
----
{sdg-name} converts PDX typed data to the corresponding application domain types if and only if the corresponding
application domain types are on the classpath and the Function-annotated POJO method expects it.
For a good example of custom, composed application-specific {data-store-name} `PdxSerializers` as well as appropriate
POJO Function parameter type handling based on the method signatures, see {sdg-name}'s
https://github.com/spring-projects/spring-data-gemfire/blob/{revnumber}/src/test/java/org/springframework/data/gemfire/function/ClientCacheFunctionExecutionWithPdxIntegrationTest.java[`ClientCacheFunctionExecutionWithPdxIntegrationTest`] class.

29
spring-data-geode-docs/src/docs/asciidoc/reference/function.adoc Normal file
View File

@@ -0,0 +1,29 @@
[[bootstrap:function]]
= Configuring the Function Service
{sdg-name} provides <<function-annotations,annotation>> support for implementing, registering and executing
{data-store-name} Functions.
{sdg-name} also provides XML namespace support for registering {data-store-name}
{x-data-store-javadoc}/org/apache/geode/cache/execute/Function.html[Functions]
for remote function execution.
See {data-store-name}'s {x-data-store-docs}/developing/function_exec/chapter_overview.html[documentation]
for more information on the Function execution framework.
{data-store-name} Functions are declared as Spring beans and must implement the `org.apache.geode.cache.execute.Function`
interface or extend `org.apache.geode.cache.execute.FunctionAdapter`.
The namespace uses a familiar pattern to declare Functions, as the following example shows:
[source,xml]
----
<gfe:function-service>
<gfe:function>
<bean class="example.FunctionOne"/>
<ref bean="function2"/>
</gfe:function>
</gfe:function-service>
<bean id="function2" class="example.FunctionTwo"/>
----

66
spring-data-geode-docs/src/docs/asciidoc/reference/gateway.adoc Normal file
View File

@@ -0,0 +1,66 @@
[[bootstrap:gateway]]
= Configuring WAN Gateways
WAN Gateways provides a way to synchronize {data-store-name} Distributed Systems across geographic locations.
{sdg-name} provides XML namespace support for configuring WAN Gateways as illustrated in the following examples.
== WAN Configuration in {data-store-name} 7.0
In the following example, `GatewaySenders` are configured for a `PARTITION` Region by adding child elements
(`gateway-sender` and `gateway-sender-ref`) to the Region. A `GatewaySender` may register `EventFilters`
and `TransportFilters`.
The following example also shows a sample configuration of an `AsyncEventQueue`, which must also be auto-wired
into a Region (not shown):
[source,xml]
----
<gfe:partitioned-region id="region-with-inner-gateway-sender" >
<gfe:gateway-sender remote-distributed-system-id="1">
<gfe:event-filter>
<bean class="org.springframework.data.gemfire.example.SomeEventFilter"/>
</gfe:event-filter>
<gfe:transport-filter>
<bean class="org.springframework.data.gemfire.example.SomeTransportFilter"/>
</gfe:transport-filter>
</gfe:gateway-sender>
<gfe:gateway-sender-ref bean="gateway-sender"/>
</gfe:partitioned-region>
<gfe:async-event-queue id="async-event-queue" batch-size="10" persistent="true" disk-store-ref="diskstore"
maximum-queue-memory="50">
<gfe:async-event-listener>
<bean class="example.AsyncEventListener"/>
</gfe:async-event-listener>
</gfe:async-event-queue>
<gfe:gateway-sender id="gateway-sender" remote-distributed-system-id="2">
<gfe:event-filter>
<ref bean="event-filter"/>
<bean class="org.springframework.data.gemfire.example.SomeEventFilter"/>
</gfe:event-filter>
<gfe:transport-filter>
<ref bean="transport-filter"/>
<bean class="org.springframework.data.gemfire.example.SomeTransportFilter"/>
</gfe:transport-filter>
</gfe:gateway-sender>
<bean id="event-filter" class="org.springframework.data.gemfire.example.AnotherEventFilter"/>
<bean id="transport-filter" class="org.springframework.data.gemfire.example.AnotherTransportFilter"/>
----
On the other end of a `GatewaySender` is a corresponding `GatewayReceiver` to receive Gateway events.
The `GatewayReceiver` may also be configured with `EventFilters` and `TransportFilters`, as follows:
[source,xml]
----
<gfe:gateway-receiver id="gateway-receiver" start-port="12345" end-port="23456" bind-address="192.168.0.1">
<gfe:transport-filter>
<bean class="org.springframework.data.gemfire.example.SomeTransportFilter"/>
</gfe:transport-filter>
</gfe:gateway-receiver>
----
See the {data-store-name}
{x-data-store-docs}/topologies_and_comm/multi_site_configuration/chapter_overview.html[documentation]
for a detailed explanation of all the configuration options.

178
spring-data-geode-docs/src/docs/asciidoc/reference/gemfire-bootstrap.adoc Normal file
View File

@@ -0,0 +1,178 @@
[[gemfire-bootstrap]]
= Bootstrapping a Spring ApplicationContext in {data-store-name}
Normally, a Spring-based application <<bootstrap,bootstraps {data-store-name}>> by using {sdg-name}'s features.
By specifying a `<gfe:cache/>` element that uses the {sdg-name} XML namespace, a single embedded {data-store-name}
peer `Cache` instance is created and initialized with default settings in the same JVM process as your application.
However, it is sometimes necessary (perhaps as a requirement imposed by your IT organization) that {data-store-name}
be fully managed and operated by the provided {data-store-name} tool suite, perhaps using
{x-data-store-docs}/tools_modules/gfsh/chapter_overview.html[Gfsh]. By using _Gfsh_, {data-store-name} bootstraps
your Spring `ApplicationContext` rather than the other way around. Instead of an application server or a Java main class
that uses Spring Boot, {data-store-name} does the bootstrapping and hosts your application.
NOTE: {data-store-name} is not an application server. In addition, there are limitations to using this approach
where the {data-store-name} cache configuration is concerned.
[[gemfire-bootstrap-gfsh]]
== Using {data-store-name} to Bootstrap a Spring Context Started with Gfsh
In order to bootstrap a Spring `ApplicationContext` in {data-store-name} when starting a {data-store-name} server
using _Gfsh_, you must use {data-store-name}'s
{x-data-store-docs}/basic_config/the_cache/setting_cache_initializer.html[initalizer] capability.
An initializer block can declare a application callback that is launched after the cache is initialized
by {data-store-name}.
An initializer is declared within an {x-data-store-docs}/reference/topics/cache_xml.html#initializer[initializer] element
by using a minimal snippet of {data-store-name}'s native `cache.xml`. To bootstrap the Spring `ApplicationContext`,
a `cache.xml` file is required, in much the same way as a minimal snippet of Spring XML config is needed to bootstrap
a Spring `ApplicationContext` configured with component scanning
(for example `<context:component-scan base-packages="..."/>`).
Fortunately, such an initializer is already conveniently provided by the framework: the
{sdg-javadoc}/org/springframework/data/gemfire/support/SpringContextBootstrappingInitializer.html[`SpringContextBootstrappingInitializer`].
The following example shows a typical, yet minimal, configuration for this class inside {data-store-name}'s
`cache.xml` file:
[source,xml]
----
<?xml version="1.0" encoding="UTF-8"?>
<cache xmlns="http://geode.apache.org/schema/cache"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://geode.apache.org/schema/cache https://geode.apache.org/schema/cache/cache-1.0.xsd"
version="1.0">
<initializer>
<class-name>org.springframework.data.gemfire.support.SpringContextBootstrappingInitializer</class-name>
<parameter name="contextConfigLocations">
<string>classpath:application-context.xml</string>
</parameter>
</initializer>
</cache>
----
The `SpringContextBootstrappingInitializer` class follows conventions similar to Spring's `ContextLoaderListener`
class, which is used to bootstrap a Spring `ApplicationContext` inside a web application, where `ApplicationContext`
configuration files are specified with the `contextConfigLocations` Servlet context parameter.
In addition, the `SpringContextBootstrappingInitializer` class can also be used with a `basePackages` parameter
to specify a comma-separated list of base packages that contain appropriately annotated application components.
The Spring container searches these components to find and create Spring beans and other application components
in the classpath, as the following example shows:
[source,xml]
----
<?xml version="1.0" encoding="UTF-8"?>
<cache xmlns="http://geode.apache.org/schema/cache"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://geode.apache.org/schema/cache https://geode.apache.org/schema/cache/cache-1.0.xsd"
version="1.0">
<initializer>
<class-name>org.springframework.data.gemfire.support.SpringContextBootstrappingInitializer</class-name>
<parameter name="basePackages">
<string>org.mycompany.myapp.services,org.mycompany.myapp.dao,...</string>
</parameter>
</initializer>
</cache>
----
Then, with a properly configured and constructed `CLASSPATH` and `cache.xml` file (shown earlier) specified as
a command-line option when starting a {data-store-name} server in _Gfsh_, the command-line would be as follows:
[source]
----
gfsh>start server --name=ExampleServer --log-level=config ...
--classpath="/path/to/application/classes.jar:/path/to/spring-data-geode-<major>.<minor>.<maint>.RELEASE.jar"
--cache-xml-file="/path/to/geode/cache.xml"
----
The `application-context.xml` can be any valid Spring configuration metadata, including all of the {sdg-acronym}
XML namespace elements. The only limitation with this approach is that a {data-store-name} cache cannot be configured
by using the {sdg-acronym} XML namespace. In other words, none of the `<gfe:cache/>` element attributes
(such as `cache-xml-location`, `properties-ref`, `critical-heap-percentage`, `pdx-serializer-ref`, `lock-lease`,
and others) can be specified. If used, these attributes are ignored.
The reason for this is that {data-store-name} itself has already created and initialized the cache before the initializer
gets invoked. As a result, the cache already exists and, since it is a "`singleton`", it cannot be re-initialized
or have any of its configuration augmented.
[[gemfire-bootstrap-lazywiring]]
== Lazy-wiring {data-store-name} Components
{sdg-name} already provides support for auto-wiring {data-store-name} components (such as `CacheListeners`,
`CacheLoaders`, `CacheWriters` and so on) that are declared and created by {data-store-name} in `cache.xml` by using
{sdg-acronym}'s `WiringDeclarableSupport` class, as described in <<apis:declarable:autowiring>>. However, this works
only when Spring is the one doing the bootstrapping (that is, when Spring bootstraps {data-store-name}).
When your Spring `ApplicationContext` is bootstrapped by {data-store-name}, these {data-store-name} application components
go unnoticed, because the Spring `ApplicationContext` does not exist yet. The Spring `ApplicationContext` does not get
created until {data-store-name} calls the initializer block, which only occurs after all the other {data-store-name}
components (cache, Regions, and others) have already been created and initialized.
To solve this problem, a new `LazyWiringDeclarableSupport` class was introduced. This new class is aware of the
Spring `ApplicationContext`. The intention behind this abstract base class is that any implementing class registers
itself to be configured by the Spring container that is eventually created by {data-store-name} once the initializer
is called. In essence, this gives your {data-store-name} application components a chance to be configured and auto-wired
with Spring beans defined in the Spring container.
In order for your {data-store-name} application components to be auto-wired by the Spring container, you should create
an application class that extends the `LazyWiringDeclarableSupport` and annotate any class member that needs to be
provided as a Spring bean dependency, similar to the following example:
[source,java]
----
public class UserDataSourceCacheLoader extends LazyWiringDeclarableSupport
implements CacheLoader<String, User> {
@Autowired
private DataSource userDataSource;
...
}
----
As implied in the `CacheLoader` example above, you might necessarily (though rarely) have defined both a Region
and a `CacheListener` component in {data-store-name} `cache.xml`. The `CacheLoader` may need access to an application
Repository (or perhaps a JDBC `DataSource` defined in the Spring `ApplicationContext`) for loading `Users` into a
{data-store-name} `REPLICATE` Region on startup.
CAUTION
====
Be careful when mixing the different life-cycles of {data-store-name} and the Spring container together in this manner.
Not all use cases and scenarios are supported. The {data-store-name} `cache.xml` configuration would be similar to
the following (which comes from {sdg-acronym}'s test suite):
[source,xml]
----
<?xml version="1.0" encoding="UTF-8"?>
<cache xmlns="http://geode.apache.org/schema/cache"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://geode.apache.org/schema/cache https://geode.apache.org/schema/cache/cache-1.0.xsd"
version="1.0">
<region name="Users" refid="REPLICATE">
<region-attributes initial-capacity="101" load-factor="0.85">
<key-constraint>java.lang.String</key-constraint>
<value-constraint>org.springframework.data.gemfire.repository.sample.User</value-constraint>
<cache-loader>
<class-name>
org.springframework.data.gemfire.support.SpringContextBootstrappingInitializerIntegrationTests$UserDataStoreCacheLoader
</class-name>
</cache-loader>
</region-attributes>
</region>
<initializer>
<class-name>org.springframework.data.gemfire.support.SpringContextBootstrappingInitializer</class-name>
<parameter name="basePackages">
<string>org.springframework.data.gemfire.support.sample</string>
</parameter>
</initializer>
</cache>
----
====

235
spring-data-geode-docs/src/docs/asciidoc/reference/indexing.adoc Normal file
View File

@@ -0,0 +1,235 @@
[[bootstrap:indexing]]
= Configuring an Index
{data-store-name} allows indexes (also sometimes pluralized as indices) to be created on Region data
to improve the performance of OQL (Object Query Language) queries.
In {sdg-name}, indexes are declared with the `index` element, as the following example shows:
[source,xml]
----
<gfe:index id="myIndex" expression="someField" from="/SomeRegion" type="HASH"/>
----
In {sdg-name}'s XML schema (also called the {sdg-acronym} XML namespace), `index` bean declarations are not bound
to a Region, unlike {data-store-name}'s native `cache.xml`. Rather, they are top-level elements similar to
`&lt;gfe:cache&gt;` element. This lets you declare any number of indexes on any Region, whether they were just created
or already exist -- a significant improvement over {data-store-name}'s native `cache.xml` format.
An `Index` must have a name. You can give the `Index` an explicit name by using the `name` attribute.
Otherwise, the bean name (that is, the value of the `id` attribute) of the `index` bean definition is used as
the `Index` name.
The `expression` and `from` clause form the main components of an `Index`, identifying the data to index
(that is, the Region identified in the `from` clause) along with what criteria (that is, `expression`) is used
to index the data. The `expression` should be based on what application domain object fields are used in the predicate
of application-defined OQL queries used to query and look up the objects stored in the Region.
Consider the following example, which has a `lastName` property:
[source,java]
----
@Region("Customers")
class Customer {
@Id
Long id;
String lastName;
String firstName;
...
}
----
Now consider the following example, which has an application-defined {sdg-acronym} Repository
to query for `Customer` objects:
[source,java]
----
interface CustomerRepository extends GemfireRepository<Customer, Long> {
Customer findByLastName(String lastName);
...
}
----
The {sdg-acronym} Repository finder/query method results in the following OQL statement being generated and ran:
[source,java]
----
SELECT * FROM /Customers c WHERE c.lastName = '$1'
----
Therefore, you might want to create an `Index` with a statement similar to the following:
[source,xml]
----
<gfe:index id="myIndex" name="CustomersLastNameIndex" expression="lastName" from="/Customers" type="HASH"/>
----
The `from` clause must refer to a valid, existing Region and is how an `Index` gets applied to a Region.
This is not specific to {sdg-name}. It is a feature of {data-store-name}.
The `Index` `type` may be one of three enumerated values defined by {sdg-name}'s
{sdg-javadoc}/org/springframework/data/gemfire/IndexType.html[`IndexType`] enumeration:
`FUNCTIONAL`, `HASH`, and `PRIMARY_KEY`.
Each of the enumerated values corresponds to one of the {x-data-store-javadoc}/org/apache/geode/cache/query/QueryService.html[`QueryService`]
`create[|Key|Hash]Index` methods invoked when the actual `Index` is to be created (or "`defined`" -- you can find
more on "`defining`" indexes in the next section). For instance, if the `IndexType` is `PRIMARY_KEY`, then the
{x-data-store-javadoc}/org/apache/geode/cache/query/QueryService.html#createKeyIndex-java.lang.String-java.lang.String-java.lang.String-[QueryService.createKeyIndex(..)]
is invoked to create a `KEY` `Index`.
The default is `FUNCTIONAL` and results in one of the `QueryService.createIndex(..)` methods being invoked. See the
{sdg-name} XML schema for a full set of options.
For more information on indexing in {data-store-name}, see "`https://gemfire90.docs.pivotal.io/geode/developing/query_index/query_index.html[Working with Indexes]`"
in {data-store-name}'s User Guide.
== Defining Indexes
In addition to creating indexes up front as `Index` bean definitions are processed by {sdg-name} on Spring container
initialization, you may also define all of your application indexes prior to creating them by using the `define`
attribute, as follows:
[source,xml]
----
<gfe:index id="myDefinedIndex" expression="someField" from="/SomeRegion" define="true"/>
----
When `define` is set to `true` (it defaults to `false`), it does not actually create the `Index` at that moment.
All "`defined`" Indexes are created all at once, when the Spring `ApplicationContext` is "`refreshed`" or, to put it
differently, when a `ContextRefreshedEvent` is published by the Spring container. {sdg-name} registers itself as
an `ApplicationListener` listening for the `ContextRefreshedEvent`. When fired, {sdg-name} calls
{x-data-store-javadoc}/org/apache/geode/cache/query/QueryService.html#createDefinedIndexes[`QueryService.createDefinedIndexes()`].
Defining indexes and creating them all at once boosts speed and efficiency when creating indexes.
See "`https://gemfire90.docs.pivotal.io/geode/developing/query_index/create_multiple_indexes.html[Creating Multiple Indexes at Once]`"
for more details.
== `IgnoreIfExists` and `Override`
Two {sdg-name} `Index` configuration options warrant special mention: `ignoreIfExists` and `override`.
These options correspond to the `ignore-if-exists` and `override` attributes on the `&lt;gfe:index&gt;` element
in {sdg-name}'s XML namespace, respectively.
WARNING: Make sure you absolutely understand what you are doing before using either of these options. These options can
affect the performance and resources (such as memory) consumed by your application at runtime. As a result, both of
these options are disabled (set to `false`) in {sdg-acronym} by default.
NOTE: These options are only available in {sdg-name} and exist to workaround known limitations with {data-store-name}.
{data-store-name} has no equivalent options or functionality.
Each option significantly differs in behavior and entirely depends on the type of {data-store-name} `Index` exception
thrown. This also means that neither option has any effect if a {data-store-name} Index-type exception is not thrown.
These options are meant to specifically handle {data-store-name} `IndexExistsException` and `IndexNameConflictException`
instances, which can occur for various, sometimes obscure reasons. The exceptions have the following causes:
* An {x-data-store-javadoc}/org/apache/geode/cache/query/IndexExistsException.html[`IndexExistsException`]
is thrown when there exists another `Index` with the same definition but a different name when attempting to
create an `Index`.
* An {x-data-store-javadoc}/org/apache/geode/cache/query/IndexNameConflictException.html[`IndexNameConflictException`]
is thrown when there exists another `Index` with the same name but possibly different definition when attempting to
create an `Index`.
{sdg-name}'s default behavior is to fail-fast, always. So, neither `Index` _Exception_ are "`handled`" by default.
These `Index` exceptions are wrapped in a {sdg-acronym} `GemfireIndexException` and rethrown. If you wish for {sdg-name}
to handle them for you, you can set either of these `Index` bean definition options to `true`.
`IgnoreIfExists` always takes precedence over `Override`, primarily because it uses fewer resources, simply because
it returns the "`existing`" `Index` in both exceptional cases.
=== `IgnoreIfExists` Behavior
When an `IndexExistsException` is thrown and `ignoreIfExists` is set to `true` (or `&lt;gfe:index ignore-if-exists="true"&gt;`),
then the `Index` that would have been created by this `index` bean definition or declaration is simply ignored,
and the existing `Index` is returned.
There is little consequence in returning the existing `Index`, since the `index` bean definition is the same,
as determined by {data-store-name} itself, not {sdg-acronym}.
However, this also means that no `Index` with the "`name`" specified in your `index` bean definition or declaration
actually exists from {data-store-name}'s perspective (that is, with
{x-data-store-javadoc}/org/apache/geode/cache/query/QueryService.html#getIndexes[`QueryService.getIndexes()`]).
Therefore, you should be careful when writing OQL query statements that use query hints, especially query hints
that refer to the application `Index` being ignored. Those query hints need to be changed.
When an `IndexNameConflictException` is thrown and `ignoreIfExists` is set to `true` (or `&lt;gfe:index ignore-if-exists="true"&gt;`),
the `Index` that would have been created by this `index` bean definition or declaration is also ignored,
and the "existing" `Index` is again returned, as when an `IndexExistsException` is thrown.
However, there is more risk in returning the existing `Index` and ignoring the application's definition of the `Index`
when an `IndexNameConflictException` is thrown. For a `IndexNameConflictException`, while the names of the conflicting
indexes are the same, the definitions could be different. This situation could have implications for OQL queries
specific to the application, where you would presume the indexes were defined specifically with the application
data access patterns and queries in mind. However, if like-named indexes differ in definition, this might not be
the case. Consequently, you should verify your `Index` names.
NOTE: {sdg-acronym} makes a best effort to inform the user when the `Index` being ignored is significantly different
in its definition from the existing `Index`. However, in order for {sdg-acronym} to accomplish this, it must be able to
find the existing `Index`, which is looked up by using the {data-store-name} API (the only means available).
=== `Override` Behavior
When an `IndexExistsException` is thrown and `override` is set to `true` (or `&lt;gfe:index override="true"&gt;`),
the `Index` is effectively renamed. Remember, `IndexExistsExceptions` are thrown when multiple indexes exist that
have the same definition but different names.
{sdg-name} can only accomplish this by using {data-store-name}'s API, by first removing the existing `Index`
and then recreating the `Index` with the new name. It is possible that either the remove or subsequent create invocation
could fail. There is no way to execute both actions atomically and rollback this joint operation if either fails.
However, if it succeeds, then you have the same problem as before with the `ignoreIfExists` option. Any existing OQL
query statement using query hints that refer to the old `Index` by name must be changed.
When an `IndexNameConflictException` is thrown and `override` is set to `true` (or `&lt;gfe:index override="true"&gt;`),
the existing `Index` can potentially be re-defined. We say "`potentially`" because it is possible for the like-named,
existing `Index` to have exactly the same definition and name when an `IndexNameConflictException` is thrown.
If so, {sdg-acronym} is smart and returns the existing `Index` as is, even on `override`. There is no harm
in this behavior, since both the name and the definition are exactly the same. Of course, {sdg-acronym} can only
accomplish this when {sdg-acronym} is able to find the existing `Index`, which is dependent on {data-store-name}'s APIs.
If it cannot be found, nothing happens and a {sdg-acronym} `GemfireIndexException` is thrown that wraps the
`IndexNameConflictException`.
However, when the definition of the existing `Index` is different, {sdg-acronym} attempts to re-create the `Index`
by using the `Index` definition specified in the `index` bean definition. Make sure this is what you want and make sure
the `index` bean definition matches your expectations and application requirements.
=== How Does `IndexNameConflictExceptions` Actually Happen?
It is probably not all that uncommon for `IndexExistsExceptions` to be thrown, especially when multiple configuration
sources are used to configure {data-store-name} ({sdg-name}, {data-store-name} Cluster Config, {data-store-name} native
`cache.xml`, the API, and so on). You should definitely prefer one configuration method and stick with it.
However, when does an `IndexNameConflictException` get thrown?
One particular case is an `Index` defined on a `PARTITION` Region (PR). When an `Index` is defined on a `PARTITION` Region
(for example, `X`), {data-store-name} distributes the `Index` definition (and name) to other peer members
in the cluster that also host the same `PARTITION` Region (that is, "X"). The distribution of this `Index` definition
to, and subsequent creation of, this `Index` by peer members is on a need-to-know basis (that is, by peer member hosting
the same PR) is performed asynchronously.
During this window of time, it is possible that these pending PR `Indexes` cannot be identified by {data-store-name} --
such as with a call to {x-data-store-javadoc}/org/apache/geode/cache/query/QueryService.html#getIndexes[`QueryService.getIndexes()`]
with {x-data-store-javadoc}/org/apache/geode/cache/query/QueryService.html#getIndexes-org.apache.geode.cache.Region[`QueryService.getIndexes(:Region)`],
or even with {x-data-store-javadoc}/org/apache/geode/cache/query/QueryService.html#getIndex-org.apache.geode.cache.Region-java.lang.String[`QueryService.getIndex(:Region, indexName:String)`].
As a result, the only way for {sdg-acronym} or other {data-store-name} cache client applications (not involving Spring)
to know for sure is to attempt to create the `Index`. If it fails with either an `IndexNameConflictException` or even
an `IndexExistsException`, the application knows there is a problem. This is because the `QueryService` `Index` creation
waits on pending `Index` definitions, whereas the other {data-store-name} API calls do not.
In any case, {sdg-acronym} makes a best effort and attempts to inform you what has happened or is happening and tell you
the corrective action. Given that all {data-store-name} `QueryService.createIndex(..)` methods are synchronous,
blocking operations, the state of {data-store-name} should be consistent and accessible after either of these index-type
exceptions are thrown. Consequently, {sdg-acronym} can inspect the state of the system and act accordingly,
based on your configuration.
In all other cases, {sdg-acronym} embraces a fail-fast strategy.

30
spring-data-geode-docs/src/docs/asciidoc/reference/introduction.adoc Normal file
View File

@@ -0,0 +1,30 @@
[[ref-introduction]]
= Document Structure
The following chapters explain the core functionality offered by {sdg-name}:
* <<bootstrap>> describes the configuration support provided for configuring, initializing, and accessing
{data-store-name} Caches, Regions, and related distributed system components.
* <<apis>> explains the integration between the {data-store-name} APIs and the various data access features
available in Spring, such as template-based data access, exception translation, transaction management, and caching.
* <<serialization>> describes enhancements to {data-store-name}'s serialization and deserialization of managed objects.
* <<mapping>> describes persistence mapping for POJOs stored in {data-store-name} using Spring Data.
* <<gemfire-repositories>> describes how to create and use Spring Data Repositories to access data
stored in {data-store-name} by using basic CRUD and simple query operations.
* <<function-annotations>> describes how to create and use {data-store-name} Functions by using annotations
to perform distributed computations where the data lives.
* <<apis:continuous-query>> describes how to use {data-store-name}'s Continuous Query (CQ) functionality
to process a stream of events based on interest that is defined and registered with {data-store-name}'s
OQL (Object Query Language).
* <<gemfire-bootstrap>> describes how to configure and bootstrap a Spring `ApplicationContext`
running in an {data-store-name} server using `Gfsh`.
* <<samples>> describes the examples provided with the distribution to illustrate the various features
available in {sdg-name}.

342
spring-data-geode-docs/src/docs/asciidoc/reference/lucene.adoc Normal file
View File

@@ -0,0 +1,342 @@
[[bootstrap:lucene]]
= Apache Lucene Integration
{x-data-store-website}[{data-store-name}] integrates with https://lucene.apache.org/[Apache Lucene] to let you
index and search on data stored in {data-store-name} by using Lucene queries. Search-based queries also include
the ability to page through query results.
Additionally, {sdg-name} adds support for query projections based on the Spring Data Commons projection infrastructure.
This feature lets the query results be projected into first-class application domain types as needed by the application.
A Lucene `Index` must be created before any Lucene search-based query can be run. A `LuceneIndex`
can be created in Spring (Data for {data-store-name}) XML config as follows:
[source,xml]
----
<gfe:lucene-index id="IndexOne" fields="fieldOne, fieldTwo" region-path="/Example"/>
----
Additionally, Apache Lucene allows the specification of
https://lucene.apache.org/core/6_5_0/core/org/apache/lucene/analysis/Analyzer.html[analyzers]
per field and can be configured as shown in the following example:
[source,xml]
----
<gfe:lucene-index id="IndexTwo" lucene-service-ref="luceneService" region-path="/AnotherExample">
<gfe:field-analyzers>
<map>
<entry key="fieldOne">
<bean class="example.AnalyzerOne"/>
</entry>
<entry key="fieldTwo">
<bean class="example.AnalyzerTwo"/>
</entry>
</map>
</gfe:field-analyzers>
</gfe:lucene-index>
----
The `Map` can be specified as a top-level bean definition and referenced by using the `ref` attribute
in the nested `<gfe:field-analyzers>` element, as follows:
`<gfe-field-analyzers ref="refToTopLevelMapBeanDefinition"/>`.
{sdg-name}'s `LuceneIndexFactoryBean` API and {sdg-acronym}'s XML namespace also lets a
{x-data-store-javadoc}/org/apache/geode/cache/lucene/LuceneSerializer.html[`org.apache.geode.cache.lucene.LuceneSerializer`]
be specified when you create the `LuceneIndex`. The `LuceneSerializer` lets you configure the way objects are converted
to Lucene documents for the index when the object is indexed.
The following example shows how to add an `LuceneSerializer` to the `LuceneIndex`:
[source,xml]
----
<bean id="MyLuceneSerializer" class="example.CustomLuceneSerializer"/>
<gfe:lucene-index id="IndexThree" lucene-service-ref="luceneService" region-path="/YetAnotherExample">
<gfe:lucene-serializer ref="MyLuceneSerializer">
</gfe:lucene-index>
----
You can specify the `LuceneSerializer` as an anonymous, nested bean definition as well, as follows:
[source,xml]
----
<gfe:lucene-index id="IndexThree" lucene-service-ref="luceneService" region-path="/YetAnotherExample">
<gfe:lucene-serializer>
<bean class="example.CustomLuceneSerializer"/>
</gfe:lucene-serializer>
</gfe:lucene-index>
----
Alternatively, you can declare or define a `LuceneIndex` in Spring Java config, inside a `@Configuration` class,
as the following example shows:
[source,java]
----
@Bean(name = "Books")
@DependsOn("bookTitleIndex")
PartitionedRegionFactoryBean<Long, Book> booksRegion(GemFireCache gemfireCache) {
PartitionedRegionFactoryBean<Long, Book> peopleRegion =
new PartitionedRegionFactoryBean<>();
peopleRegion.setCache(gemfireCache);
peopleRegion.setClose(false);
peopleRegion.setPersistent(false);
return peopleRegion;
}
@Bean
LuceneIndexFactoryBean bookTitleIndex(GemFireCache gemFireCache,
LuceneSerializer luceneSerializer) {
LuceneIndexFactoryBean luceneIndex = new LuceneIndexFactoryBean();
luceneIndex.setCache(gemFireCache);
luceneIndex.setFields("title");
luceneIndex.setLuceneSerializer(luceneSerializer);
luceneIndex.setRegionPath("/Books");
return luceneIndex;
}
@Bean
CustomLuceneSerializer myLuceneSerialier() {
return new CustomeLuceneSerializer();
}
----
There are a few limitations of {data-store-name}'s, Apache Lucene integration and support.
First, a `LuceneIndex` can only be created on a {data-store-name} `PARTITION` Region.
Second, all `LuceneIndexes` must be created before the Region to which the `LuceneIndex` applies.
NOTE: To help ensure that all declared `LuceneIndexes` defined in a Spring container are created before the Regions
on which they apply, {sdg-acronym} includes the `org.springframework.data.gemfire.config.support.LuceneIndexRegionBeanFactoryPostProcessor`.
You may register this Spring {spring-framework-javadoc}/org/springframework/beans/factory/config/BeanFactoryPostProcessor.html[`BeanFactoryPostProcessor`]
in XML config by using `<bean class="org.springframework.data.gemfire.config.support.LuceneIndexRegionBeanFactoryPostProcessor"/>`.
The `o.s.d.g.config.support.LuceneIndexRegionBeanFactoryPostProcessor` may only be used when using {sdg-acronym} XML config.
More details about Spring's `BeanFactoryPostProcessors` can be found {spring-framework-docs}/core.html#beans-factory-extension-factory-postprocessors[here].
It is possible that these {data-store-name} restrictions will not apply in a future release which is why
the {sdg-acronym} `LuceneIndexFactoryBean` API takes a reference to the Region directly as well,
rather than just the Region path.
This is more ideal when you want to define a `LuceneIndex` on an existing Region with data at a later point
during the application's lifecycle and as requirements demand. Where possible, {sdg-acronym} strives to adhere to
strongly-typed objects. However, for the time being, you must use the `regionPath` property to specify the Region
to which the `LuceneIndex` is applied.
NOTE: Additionally, in the preceding example, note the presence of Spring's `@DependsOn` annotation
on the `Books` Region bean definition. This creates a dependency from the `Books` Region bean to the `bookTitleIndex`
`LuceneIndex` bean definition, ensuring that the `LuceneIndex` is created before the Region on which it applies.
Now that once we have a `LuceneIndex`, we can perform Lucene-based data access operations, such as queries.
== Lucene Template Data Accessors
{sdg-name} provides two primary templates for Lucene data access operations, depending on how low of a level
your application is prepared to deal with.
The `LuceneOperations` interface defines query operations by using {data-store-name}
{x-data-store-javadoc}/org/apache/geode/cache/lucene/package-summary.html[Lucene types],
which are defined in the following interface definition:
[source,java]
----
public interface LuceneOperations {
<K, V> List<LuceneResultStruct<K, V>> query(String query, String defaultField [, int resultLimit]
, String... projectionFields);
<K, V> PageableLuceneQueryResults<K, V> query(String query, String defaultField,
int resultLimit, int pageSize, String... projectionFields);
<K, V> List<LuceneResultStruct<K, V>> query(LuceneQueryProvider queryProvider [, int resultLimit]
, String... projectionFields);
<K, V> PageableLuceneQueryResults<K, V> query(LuceneQueryProvider queryProvider,
int resultLimit, int pageSize, String... projectionFields);
<K> Collection<K> queryForKeys(String query, String defaultField [, int resultLimit]);
<K> Collection<K> queryForKeys(LuceneQueryProvider queryProvider [, int resultLimit]);
<V> Collection<V> queryForValues(String query, String defaultField [, int resultLimit]);
<V> Collection<V> queryForValues(LuceneQueryProvider queryProvider [, int resultLimit]);
}
----
NOTE: The `[, int resultLimit]` indicates that the `resultLimit` parameter is optional.
The operations in the `LuceneOperations` interface match the operations provided by the {data-store-name}'s
{x-data-store-javadoc}/org/apache/geode/cache/lucene/LuceneQuery.html[LuceneQuery] interface.
However, {sdg-acronym} has the added value of translating proprietary {data-store-name} or Apache Lucene `Exceptions`
into Spring's highly consistent and expressive DAO
https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#dao-exceptions[exception hierarchy],
particularly as many modern data access operations involve more than one store or repository.
Additionally, {sdg-acronym}'s `LuceneOperations` interface can shield your application from interface-breaking changes
introduced by the underlying {data-store-name} or Apache Lucene APIs when they occur.
However, it would be sad to offer a Lucene Data Access Object (DAO) that only uses {data-store-name} and Apache Lucene
data types (such as {data-store-name}'s `LuceneResultStruct`). Therefore, {sdg-acronym} gives you the
`ProjectingLuceneOperations` interface to remedy these important application concerns. The following listing shows
the `ProjectingLuceneOperations` interface definition:
[source,java]
----
public interface ProjectingLuceneOperations {
<T> List<T> query(String query, String defaultField [, int resultLimit], Class<T> projectionType);
<T> Page<T> query(String query, String defaultField, int resultLimit, int pageSize, Class<T> projectionType);
<T> List<T> query(LuceneQueryProvider queryProvider [, int resultLimit], Class<T> projectionType);
<T> Page<T> query(LuceneQueryProvider queryProvider, int resultLimit, int pageSize, Class<T> projectionType);
}
----
The `ProjectingLuceneOperations` interface primarily uses application domain object types that let you work with
your application data. The `query` method variants accept a projection type, and the template applies the query results
to instances of the given projection type by using the Spring Data Commons Projection infrastructure.
Additionally, the template wraps the paged Lucene query results in an instance of the Spring Data Commons
`Page` abstraction. The same projection logic can still be applied to the results in the page and are lazily projected
as each page in the collection is accessed.
By way of example, suppose you have a class representing a `Person`, as follows:
[source,java]
----
class Person {
Gender gender;
LocalDate birthDate;
String firstName;
String lastName;
...
String getName() {
return String.format("%1$s %2$s", getFirstName(), getLastName());
}
}
----
Additionally, you might have a single interface to represent people as `Customers`, depending on your application view,
as follows:
[source,java]
----
interface Customer {
String getName()
}
----
If I define the following `LuceneIndex`...
[source,java]
----
@Bean
LuceneIndexFactoryBean personLastNameIndex(GemFireCache gemfireCache) {
LuceneIndexFactoryBean personLastNameIndex =
new LuceneIndexFactoryBean();
personLastNameIndex.setCache(gemfireCache);
personLastNameIndex.setFields("lastName");
personLastNameIndex.setRegionPath("/People");
return personLastNameIndex;
}
----
Then you could query for people as `Person` objects, as follows:
[source,java]
----
List<Person> people = luceneTemplate.query("lastName: D*", "lastName", Person.class);
----
Alternatively, you could query for a `Page` of type `Customer`, as follows:
[source,java]
----
Page<Customer> customers = luceneTemplate.query("lastName: D*", "lastName", 100, 20, Customer.class);
----
The `Page` can then be used to fetch individual pages of the results, as follows:
[source,java]
----
List<Customer> firstPage = customers.getContent();
----
Conveniently, the Spring Data Commons `Page` interface also implements `java.lang.Iterable<T>`, making it easy
to iterate over the contents.
The only restriction to the Spring Data Commons Projection infrastructure is that the projection type must be
an interface. However, it is possible to extend the provided SDC Projection infrastructure and provide a custom
https://docs.spring.io/spring-data/commons/docs/current/api/org/springframework/data/projection/ProjectionFactory.html[`ProjectionFactory`]
that uses https://github.com/cglib/cglib[CGLIB] to generate proxy classes as the projected entity.
You can use `setProjectionFactory(:ProjectionFactory)` to set a custom `ProjectionFactory` on a Lucene template.
== Annotation Configuration Support
Finally, {sdg-name} provides annotation configuration support for `LuceneIndexes`.
Eventually, the {sdg-acronym} Lucene support will finds its way into the Repository infrastructure extension for
{data-store-name} so that Lucene queries can be expressed as methods on an application `Repository` interface,
in much the same way as the <<gemfire-repositories.queries.executing,OQL support>> works today.
However, in the meantime, if you want to conveniently express `LuceneIndexes`, you can do so directly on
your application domain objects, as the following example shows:
[source,java]
----
@PartitionRegion("People")
class Person {
Gender gender;
@Index
LocalDate birthDate;
String firstName;
@LuceneIndex;
String lastName;
...
}
----
To enable this feature, you must use {sdg-acronym}'s annotation configuration support specifically with the
`@EnableEntityDefineRegions` and `@EnableIndexing` annotations, as follows:
[source,java]
----
@PeerCacheApplication
@EnableEntityDefinedRegions
@EnableIndexing
class ApplicationConfiguration {
...
}
----
NOTE: `LuceneIndexes` can only be created on {data-store-name} servers since `LuceneIndexes` only apply
to `PARTITION` Regions.
Given our earlier definition of the `Person` class, the {sdg-acronym} annotation configuration support finds
the `Person` entity class definition and determines that people are stored in a `PARTITION` Region called "`People`"
and that the `Person` has an OQL `Index` on `birthDate` along with a `LuceneIndex` on `lastName`.

443
spring-data-geode-docs/src/docs/asciidoc/reference/mapping.adoc Normal file
View File

@@ -0,0 +1,443 @@
[[mapping]]
= POJO Mapping
This section covers:
* <<mapping.entities>>
* <<mapping.repositories>>
* <<mapping.pdx-serializer>>
include::../{spring-data-commons-include}/object-mapping.adoc[leveloffset=+1]
[[mapping.entities]]
== Entity Mapping
{sdg-name} provides support to map entities that are stored in a Region. The mapping metadata is defined by
using annotations on application domain classes, as the following example shows:
.Mapping a domain class to a {data-store-name} Region
====
[source,java]
----
@Region("People")
public class Person {
@Id Long id;
String firstname;
String lastname;
@PersistenceConstructor
public Person(String firstname, String lastname) {
// …
}
…
}
----
====
The `@Region` annotation can be used to customize the Region in which an instance of the `Person` class is stored.
The `@Id` annotation can be used to annotate the property that should be used as the cache Region key, identifying
the Region entry. The `@PersistenceConstructor` annotation helps to disambiguate multiple potentially available
constructors, taking parameters and explicitly marking the constructor annotated as the constructor to be used to
construct entities. In an application domain class with no or only a single constructor, you can omit the annotation.
In addition to storing entities in top-level Regions, entities can be stored in Sub-Regions as well,
as the following example shows:
[source,java]
----
@Region("/Users/Admin")
public class Admin extends User {
…
}
@Region("/Users/Guest")
public class Guest extends User {
…
}
----
Be sure to use the full path of the {data-store-name} Region, as defined with the {sdg-name} XML namespace
by using the `id` or `name` attributes of the `<*-region>` element.
[[mapping.entities.region]]
=== Entity Mapping by Region Type
In addition to the `@Region` annotation, {sdg-name} also recognizes type-specific Region mapping annotations:
`@ClientRegion`, `@LocalRegion`, `@PartitionRegion`, and `@ReplicateRegion`.
Functionally, these annotations are treated exactly the same as the generic `@Region` annotation in the {sdg-acronym}
mapping infrastructure. However, these additional mapping annotations are useful in {sdg-name}'s
annotation configuration model. When combined with the `@EnableEntityDefinedRegions` configuration annotation
on a Spring `@Configuration` annotated class, it is possible to generate Regions in the local cache, whether
the application is a client or peer.
These annotations let you be more specific about what type of Region your application entity class should be mapped to
and also has an impact on the data management policies of the Region (for example, partition -- also known as sharding
-- versus replicating data).
Using these type-specific Region mapping annotations with the {sdg-acronym} annotation configuration model saves you
from having to explicitly define these Regions in configuration.
[[mapping.repositories]]
== Repository Mapping
As an alternative to specifying the Region in which the entity is stored by using the `@Region` annotation
on the entity class, you can also specify the `@Region` annotation on the entity's `Repository` interface.
See <<gemfire-repositories>> for more details.
However, suppose you want to store a `Person` record in multiple {data-store-name} Regions (for example, `People`
and `Customers`). Then you can define your corresponding `Repository` interface extensions as follows:
[source,java]
----
@Region("People")
public interface PersonRepository extends GemfireRepository<Person, String> {
…
}
@Region("Customers")
public interface CustomerRepository extends GemfireRepository<Person, String> {
...
}
----
Then, using each Repository individually, you can store the entity in multiple {data-store-name} Regions,
as the following example shows:
[source,java]
----
@Service
class CustomerService {
CustomerRepository customerRepo;
PersonRepository personRepo;
Customer update(Customer customer) {
customerRepo.save(customer);
personRepo.save(customer);
return customer;
}
----
You can even wrap the `update` service method in a Spring managed transaction, either as a local cache transaction
or a global transaction.
[[mapping.pdx-serializer]]
== MappingPdxSerializer
{sdg-name} provides a custom {x-data-store-javadoc}/org/apache/geode/pdx/PdxSerializer.html[`PdxSerializer`]
implementation, called `MappingPdxSerializer`, that uses Spring Data mapping metadata to customize entity serialization.
The serializer also lets you customize entity instantiation by using the Spring Data `EntityInstantiator` abstraction.
By default, the serializer use the `ReflectionEntityInstantiator`, which uses the persistence constructor of
the mapped entity. The persistence constructor is either the default constructor, a singly declared constructor,
or a constructor explicitly annotated with `@PersistenceConstructor`.
To provide arguments for constructor parameters, the serializer reads fields with the named constructor parameter,
explicitly identified by using Spring's `@Value` annotation, from the supplied
{x-data-store-javadoc}/org/apache/geode/pdx/PdxReader.html[`PdxReader`],
as shown in the following example:
.Using `@Value` on entity constructor parameters
====
[source,java]
----
public class Person {
public Person(@Value("#root.thing") String firstName, @Value("bean") String lastName) {
…
}
}
----
====
An entity class annotated in this way has the "`thing`" field read from the `PdxReader` and passed as the argument value
for the constructor parameter, `firstname`. The value for `lastName` is a Spring bean with the name "`bean`".
In addition to the custom instantiation logic and strategy provided by `EntityInstantiators`,
the `MappingPdxSerializer` also provides capabilities well beyond {data-store-name}'s own
{x-data-store-javadoc}/org/apache/geode/pdx/ReflectionBasedAutoSerializer.html[`ReflectionBasedAutoSerializer`].
While {data-store-name}'s `ReflectionBasedAutoSerializer` conveniently uses Java Reflection to populate entities
and uses regular expressions to identify types that should be handled (serialized and deserialized) by the serializer,
it cannot, unlike `MappingPdxSerializer`, perform the following:
* Register custom `PdxSerializer` objects per entity field or property names and types.
* Conveniently identifies ID properties.
* Automatically handles read-only properties.
* Automatically handles transient properties.
* Allows more robust type filtering in a `null` and type-safe manner (for example, not limited to
only expressing types with regex).
We now explore each feature of the `MappingPdxSerializer` in a bit more detail.
[[mapping.pdx-serializer.custom-serialization]]
=== Custom PdxSerializer Registration
The `MappingPdxSerializer` gives you the ability to register custom `PdxSerializers` based on an entity's field
or property names and types.
For example, suppose you have defined an entity type modeling a `User` as follows:
[source,java]
----
package example.app.security.auth.model;
public class User {
private String name;
private Password password;
...
}
----
While the user's name probably does not require any special logic to serialize the value, serializing the password
on the other hand might require additional logic to handle the sensitive nature of the field or property.
Perhaps you want to protect the password when sending the value over the network, between a client and a server,
beyond TLS alone, and you only want to store the salted hash. When using the `MappingPdxSerializer`, you can register
a custom `PdxSerializer` to handle the user's password, as follows:
.Registering custom `PdxSerializers` by POJO field/property type
====
[source,java]
----
Map<?, PdxSerializer> customPdxSerializers = new HashMap<>();
customPdxSerializers.put(Password.class, new SaltedHashPasswordPdxSerializer());
mappingPdxSerializer.setCustomPdxSerializers(customPdxSerializers);
----
====
After registering the application-defined `SaltedHashPasswordPdxSerializer` instance with the `Password`
application domain model type, the `MappingPdxSerializer` will then consult the custom `PdxSerializer`
to serialize and deserialize all `Password` objects regardless of the containing object (for example, `User`).
However, suppose you want to customize the serialization of `Passwords` only on `User` objects.
To do so, you can register the custom `PdxSerializer` for the `User` type by specifying the fully qualified name
of the `Class's` field or property, as the following example shows:
.Registering custom `PdxSerializers` by POJO field/property name
====
[source,java]
----
Map<?, PdxSerializer> customPdxSerializers = new HashMap<>();
customPdxSerializers.put("example.app.security.auth.model.User.password", new SaltedHashPasswordPdxSerializer());
mappingPdxSerializer.setCustomPdxSerializers(customPdxSerializers);
----
====
Notice the use of the fully-qualified field or property name (that is `example.app.security.auth.model.User.password`)
as the custom `PdxSerializer` registration key.
NOTE: You could construct the registration key by using a more logical code snippet, such as the following:
`User.class.getName().concat(".password");`. We recommended this over the example shown earlier.
The preceding example tried to be as explicit as possible about the semantics of registration.
[[mapping.pdx-serializer.id-properties]]
=== Mapping ID Properties
Like {data-store-name}'s `ReflectionBasedAutoSerializer`, {sdg-acronym}'s `MappingPdxSerializer` is also able to
determine the identifier of the entity. However, `MappingPdxSerializer` does so by using Spring Data's mapping metadata,
specifically by finding the entity property designated as the identifier using Spring Data's
{spring-data-commons-javadoc}/org/springframework/data/annotation/Id.html[`@Id`] annotation.
Alternatively, any field or property named "`id`", not explicitly annotated with `@Id`, is also designated as
the entity's identifier.
For example:
[source,java]
----
class Customer {
@Id
Long id;
...
}
----
In this case, the `Customer` `id` field is marked as the identifier field in the PDX type metadata by using
{x-data-store-javadoc}/org/apache/geode/pdx/PdxWriter.html#markIdentityField-java.lang.String-[`PdxWriter.markIdentifierField(:String)`]
when the `PdxSerializer.toData(..)` method is called during serialization.
[[mapping.pdx-serializer.read-only-properties]]
=== Mapping Read-only Properties
What happens when your entity defines a read-only property?
First, it is important to understand what a "`read-only`" property is. If you define a POJO by following the
https://www.oracle.com/technetwork/java/javase/documentation/spec-136004.html[JavaBeans] specification (as Spring does),
you might define a POJO with a read-only property, as follows:
[source,java]
----
package example;
class ApplicationDomainType {
private AnotherType readOnly;
public AnotherType getReadOnly() [
this.readOnly;
}
...
}
----
The `readOnly` property is read-only because it does not provide a setter method. It only has a getter method.
In this case, the `readOnly` property (not to be confused with the `readOnly` `DomainType` field)
is considered read-only.
As a result, the `MappingPdxSerializer` will not try to set a value for this property when populating an instance of
`ApplicationDomainType` in the `PdxSerializer.fromData(:Class<ApplicationDomainType>, :PdxReader)` method
during deserialization, particularly if a value is present in the PDX serialized bytes.
This is useful in situations where you might be returning a view or projection of some entity type and you only want
to set state that is writable. Perhaps the view or projection of the entity is based on authorization or some other
criteria. The point is, you can leverage this feature as is appropriate for your application's use cases
and requirements. If you want the field or property to always be written, simply define a setter method.
[[mapping.pdx-serializer.transient-properties]]
=== Mapping Transient Properties
Likewise, what happens when your entity defines `transient` properties?
You would expect the `transient` fields or properties of your entity not to be serialized to PDX when serializing
the entity. That is exactly what happens, unlike {data-store-name}'s own `ReflectionBasedAutoSerializer`,
which serializes everything accessible from the object through Java Reflection.
The `MappingPdxSerializer` will not serialize any fields or properties that are qualified as being transient, either
by using Java's own `transient` keyword (in the case of class instance fields) or by using the
{spring-data-commons-javadoc}/org/springframework/data/annotation/Transient.html[`@Transient`]
Spring Data annotation on either fields or properties.
For example, you might define an entity with transient fields and properties as follows:
[source,java]
----
package example;
class Process {
private transient int id;
private File workingDirectory;
private String name;
private Type type;
@Transient
public String getHostname() {
...
}
...
}
----
Neither the `Process` `id` field nor the readable `hostname` property are written to PDX.
[[mapping.pdx-serializer.type-filtering]]
=== Filtering by Class Type
Similar to {data-store-name}'s `ReflectionBasedAutoSerializer`, {sdg-acronym}'s `MappingPdxSerializer` lets you filter
the types of objects that are serialized and deserialized.
However, unlike {data-store-name}'s `ReflectionBasedAutoSerializer`, which uses complex regular expressions to express
which types the serializer handles, {sdg-acronym}'s `MappingPdxSerializer` uses the much more robust
https://docs.oracle.com/javase/8/docs/api/java/util/function/Predicate.html[`java.util.function.Predicate`] interface
and API to express type-matching criteria.
TIP: If you like to use regular expressions, you can implement a `Predicate` using Java's
https://docs.oracle.com/javase/8/docs/api/java/util/regex/package-summary.html[regular expression support].
The nice part about Java's `Predicate` interface is that you can compose `Predicates` by using convenient
and appropriate API methods, including:
https://docs.oracle.com/javase/8/docs/api/java/util/function/Predicate.html#and-java.util.function.Predicate-[`and(:Predicate)`],
https://docs.oracle.com/javase/8/docs/api/java/util/function/Predicate.html#or-java.util.function.Predicate-[`or(:Predicate)`],
and https://docs.oracle.com/javase/8/docs/api/java/util/function/Predicate.html#negate--[`negate()`].
The following example shows the `Predicate` API in action:
[source,java]
----
Predicate<Class<?>> customerTypes =
type -> Customer.class.getPackage().getName().startsWith(type.getName()); // Include all types in the same package as `Customer`
Predicate includedTypes = customerTypes
.or(type -> User.class.isAssignble(type)); // Additionally, include User sub-types (e.g. Admin, Guest, etc)
mappingPdxSerializer.setIncludeTypeFilters(includedTypes);
mappingPdxSerializer.setExcludeTypeFilters(
type -> !Reference.class.getPackage(type.getPackage()); // Exclude Reference types
----
NOTE: Any `Class` object passed to your `Predicate` is guaranteed not to be `null`.
{sdg-acronym}'s `MappingPdxSerializer` includes support for both include and exclude class type filters.
[[mapping.pdx-serializer.type-filtering.execludes]]
==== Exclude Type Filtering
By default, {sdg-acronym}'s `MappingPdxSerializer` registers pre-defined `Predicates` that filter, or exclude types
from the folliowing packages:
* `java.*`
* `com.gemstone.gemfire.*`
* `org.apache.geode.*`
* `org.springframework.*`
In addition, the `MappingPdxSerializer` filters `null` objects when calling `PdxSerializer.toData(:Object, :PdxWriter)`
and `null` class types when calling `PdxSerializer.fromData(:Class<?>, :PdxReader)` methods.
It is very easy to add exclusions for other class types, or an entire package of types, by simply defining a `Predicate`
and adding it to the `MappingPdxSerializer` as shown earlier.
The `MappingPdxSerializer.setExcludeTypeFilters(:Predicate<Class<?>>)` method is additive, meaning it composes
your application-defined type filters with the existing, pre-defined type filter `Predicates` indicated above
using the `Predicate.and(:Predicate<Class<?>>)` method.
However, what if you want to include a class type (for example, `java.security Principal`) implicitly excluded by
the exclude type filters? See <<mapping.pdx-serializer.type-filtering.includes>>.
[[mapping.pdx-serializer.type-filtering.includes]]
==== Include Type Filtering
If you want to include a class type explicitly, or override a class type filter that implicitly excludes a class type
required by your application (for example, `java.security.Principal`, which is excluded by default with the `java.*`
package exclude type filter on `MappingPdxSerializer`), then just define the appropriate `Predicate` and add it to
the serializer using `MappingPdxSerializer.setIncludeTypeFilters(:Predicate<Class<?>>)` method, as follows:
[source,java]
----
Predicate<Class<?>> principalTypeFilter =
type -> java.security.Principal.class.isAssignableFrom(type);
mappingPdxSerializer.setIncludeTypeFilters(principalTypeFilters);
----
Again, the `MappingPdxSerializer.setIncludeTypeFilters(:Predicate<Class<?>>)` method,
like `setExcludeTypeFilters(:Predicate<Class<?>>)`, is additive and therefore composes any passed type filter
using `Predicate.or(:Predicate<Class<?>>)`. This means you may call `setIncludeTypeFilters(:Predicate<Class<?>>)`
as many time as necessary.
When include type filters are present, then the `MappingPdxSerializer` makes a decision of whether to de/serialize
an instance of a class type when the class type is either not implicitly excluded OR when the class type
is explicitly included, whichever returns true. Then, an instance of the class type will be serialized
or deserialized appropriately.
For example, when a type filter of `Predicate<Class<Principal>>` is explicitly registered as shown previously,
it cancels out the implicit exclude type filter on `java.*` package types.

1281
spring-data-geode-docs/src/docs/asciidoc/reference/region.adoc Normal file
View File

File diff suppressed because it is too large Load Diff

531
spring-data-geode-docs/src/docs/asciidoc/reference/repositories.adoc Normal file
View File

@@ -0,0 +1,531 @@
[[gemfire-repositories]]
= {sdg-name} Repositories
{sdg-name} provides support for using the Spring Data Repository abstraction to easily persist entities into
{data-store-name} along with executing queries. A general introduction to the Repository programming model
is provided https://docs.spring.io/spring-data/data-commons/docs/current/reference/html/#repositories[here].
[[gemfire-repositories.spring-configuration-xml]]
== Spring XML Configuration
To bootstrap Spring Data Repositories, use the `<repositories/>` element from the {sdg-name} Data namespace,
as the following example shows:
.Bootstrap {sdg-name} Repositories in XML
====
[source,xml]
[subs="verbatim,attributes"]
----
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:gfe-data="{spring-data-access-schema-namespace}"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
{spring-data-access-schema-namespace} {spring-data-access-schema-location}
">
<gfe-data:repositories base-package="com.example.acme.repository"/>
</beans>
----
====
The preceding configuration snippet looks for interfaces below the configured base package and creates Repository instances
for those interfaces backed by a https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/repository/support/SimpleGemfireRepository.html[`SimpleGemFireRepository`].
IMPORTANT: The bootstrap process fails unless you have your application domain classes correctly mapped
to configured Regions.
[[gemfire-repositories.spring-configuration-java]]
== Spring Java-based Configuration
Alternatively, many developers prefer to use Spring's {spring-framework-docs}/core.html#beans-java[Java-based container configuration].
Using this approach, you can bootstrap Spring Data Repositories by using the {sdg-acronym} `@EnableGemfireRepositories`
annotation, as the following example shows:
.Bootstrap {sdg-name} Repositories with `@EnableGemfireRepositories`
====
[source, java]
----
@SpringBootApplication
@EnableGemfireRepositories(basePackages = "com.example.acme.repository")
class SpringDataApplication {
...
}
----
====
Rather than use the `basePackages` attribute, you may prefer to use the type-safe `basePackageClasses` attribute instead.
The `basePackageClasses` lets you specify the package that contains all your application Repository classes by
specifying only one of your application Repository interface types. Consider creating a special no-op marker class
or interface in each package that serves no purpose other than to identify the location of application Repositories
referenced by this attribute.
In addition to the `basePackages and basePackageClasses` attributes, like Spring's
{spring-framework-javadoc}/org/springframework/context/annotation/ComponentScan.html[`@ComponentScan`] annotation,
the `@EnableGemfireRepositories` annotation provides include and exclude filters, based on Spring's
{spring-framework-javadoc}/org/springframework/context/annotation/ComponentScan.Filter.html[`ComponentScan.Filter`] type.
You can use the `filterType` attribute to filter by different aspects, such as whether an application Repository type
is annotated with a particular annotation or extends a particular class type and so on. See the
{spring-framework-javadoc}/org/springframework/context/annotation/FilterType.html[`FilterType` Javadoc]
for more details.
The `@EnableGemfireRepositories` annotation also lets you specify the location of named OQL queries, which reside in
a Java `Properties` file, by using the `namedQueriesLocation` attribute. The property name must match the name
of a Repository query method and the property value is the OQL query you want executed when the Repository query method
is called.
The `repositoryImplementationPostfix` attribute can be set to an alternate value (defaults to `Impl`) if your
application requires one or more {spring-data-commons-docs-html}/#repositories.custom-implementations[custom repository implementations].
This feature is commonly used to extend the Spring Data Repository infrastructure to implement a feature not provided by
the data store (for example, {sdg-acronym}).
One example of where custom repository implementations are needed with {data-store-name} is when performing joins.
Joins are not supported by {sdg-acronym} Repositories. With a {data-store-name} `PARTITION` Region, the join must be
performed on collocated `PARTITION` Regions, since {data-store-name} does not support "`distributed`" joins.
In addition, the Equi-Join OQL Query must be performed inside a {data-store-name} Function.
See https://gemfire91.docs.pivotal.io/geode/developing/partitioned_regions/join_query_partitioned_regions.html[here]
for more details on {data-store-name} _Equi-Join Queries_.
Many other aspects of the {sdg-acronym}'s Repository infrastructure extension may be customized as well. See the
https://docs.spring.io/spring-data/gemfire/docs/current/api/org/springframework/data/gemfire/repository/config/EnableGemfireRepositories.html[`@EnableGemfireRepositories`]
Javadoc for more details on all configuration settings.
[[gemfire-repositories.queries.executing]]
== Executing OQL Queries
{sdg-name} Repositories enable the definition of query methods to easily execute {data-store-name} OQL queries
against the Region the managed entity maps to, as the following example shows:
.Sample Repository
====
[source,java]
----
@Region("People")
public class Person { … }
----
[source,java]
----
public interface PersonRepository extends CrudRepository<Person, Long> {
Person findByEmailAddress(String emailAddress);
Collection<Person> findByFirstname(String firstname);
@Query("SELECT * FROM /People p WHERE p.firstname = $1")
Collection<Person> findByFirstnameAnnotated(String firstname);
@Query("SELECT * FROM /People p WHERE p.firstname IN SET $1")
Collection<Person> findByFirstnamesAnnotated(Collection<String> firstnames);
}
----
====
The first query method listed in the preceding example causes the following OQL query to be derived:
`SELECT x FROM /People x WHERE x.emailAddress = $1`. The second query method works the same way except
it returns all entities found, whereas the first query method expects a single result to be found.
If the supported keywords are not sufficient to declare and express your OQL query, or the method name becomes too
verbose, then you can annotate the query methods with `@Query` as shown on the third and fourth methods.
The following table gives brief samples of the supported keywords that you can use in query methods:
[cols="1,2,2", options="header"]
.Supported keywords for query methods
|===
| Keyword
| Sample
| Logical result
| `GreaterThan`
| `findByAgeGreaterThan(int age)`
| `x.age > $1`
| `GreaterThanEqual`
| `findByAgeGreaterThanEqual(int age)`
| `x.age >= $1`
| `LessThan`
| `findByAgeLessThan(int age)`
| `x.age < $1`
| `LessThanEqual`
| `findByAgeLessThanEqual(int age)`
| `x.age <= $1`
| `IsNotNull`, `NotNull`
| `findByFirstnameNotNull()`
| `x.firstname =! NULL`
| `IsNull`, `Null`
| `findByFirstnameNull()`
| `x.firstname = NULL`
| `In`
| `findByFirstnameIn(Collection<String> x)`
| `x.firstname IN SET $1`
| `NotIn`
| `findByFirstnameNotIn(Collection<String> x)`
| `x.firstname NOT IN SET $1`
| `IgnoreCase`
| `findByFirstnameIgnoreCase(String firstName)`
| `x.firstname.equalsIgnoreCase($1)`
| (No keyword)
| `findByFirstname(String name)`
| `x.firstname = $1`
| `Like`
| `findByFirstnameLike(String name)`
| `x.firstname LIKE $1`
| `Not`
| `findByFirstnameNot(String name)`
| `x.firstname != $1`
| `IsTrue`, `True`
| `findByActiveIsTrue()`
| `x.active = true`
| `IsFalse`, `False`
| `findByActiveIsFalse()`
| `x.active = false`
|===
[[gemfire-repositories.queries.oql-extensions]]
== OQL Query Extensions Using Annotations
Many query languages, such as {data-store-name}'s OQL (Object Query Language), have extensions that are not directly
supported by Spring Data Commons' Repository infrastructure.
One of Spring Data Commons' Repository infrastructure goals is to function as the lowest common denominator to maintain
support for and portability across the widest array of data stores available and in use for application development
today. Technically, this means developers can access multiple different data stores supported by Spring Data Commons
within their applications by reusing their existing application-specific Repository interfaces -- a convenient
and powerful abstraction.
To support {data-store-name}'s OQL Query language extensions and preserve portability across different data stores,
{sdg-name} adds support for OQL Query extensions by using Java annotations. These annotations are ignored by other
Spring Data Repository implementations (such as Spring Data JPA or Spring Data Redis) that do not have similar
query language features.
For instance, many data stores most likely do not implement {data-store-name}'s OQL `IMPORT` keyword. Implementing `IMPORT`
as an annotation (that is, `@Import`) rather than as part of the query method signature (specifically, the method 'name')
does not interfere with the parsing infrastructure when evaluating the query method name to construct another data store
language appropriate query.
Currently, the set of {data-store-name} OQL Query language extensions that are supported by {sdg-name} include:
[cols="1,2,2,2", options="header"]
.Supported {data-store-name} OQL extensions for Repository query methods
|===
| Keyword
| Annotation
| Description
| Arguments
| {x-data-store-docs}/developing/query_index/query_index_hints.html#topic_cfb_mxn_jq[HINT]
| `@Hint`
| OQL query index hints
| `String[]` (e.g. @Hint({ "IdIdx", "TxDateIdx" }))
| {x-data-store-docs}/developing/query_select/the_import_statement.html#concept_2E9F15B2FE9041238B54736103396BF7[IMPORT]
| `@Import`
| Qualify application-specific types.
| `String` (e.g. @Import("org.example.app.domain.Type"))
| {x-data-store-docs}/developing/query_select/the_select_statement.html#concept_85AE7D6B1E2941ED8BD2A8310A81753E__section_25D7055B33EC47B19B1B70264B39212F[LIMIT]
| `@Limit`
| Limit the returned query result set.
| `Integer` (e.g. @Limit(10); default is Integer.MAX_VALUE)
| {x-data-store-docs}/developing/query_additional/query_debugging.html#concept_2D557E24AAB24044A3DB36B3124F6748[TRACE]
| `@Trace`
| Enable OQL query-specific debugging.
| NA
|===
As an example, suppose you have a `Customers` application domain class and corresponding {data-store-name} Region
along with a `CustomerRepository` and a query method to lookup `Customers` by last name, as follows:
.Sample Customers Repository
====
[source,java]
----
package ...;
import org.springframework.data.annotation.Id;
import org.springframework.data.gemfire.mapping.annotation.Region;
...
@Region("Customers")
public class Customer ... {
@Id
private Long id;
...
}
----
[source,java]
----
package ...;
import org.springframework.data.gemfire.repository.GemfireRepository;
...
public interface CustomerRepository extends GemfireRepository<Customer, Long> {
@Trace
@Limit(10)
@Hint("LastNameIdx")
@Import("org.example.app.domain.Customer")
List<Customer> findByLastName(String lastName);
...
}
----
====
The preceding example results in the following OQL Query:
`<TRACE> <HINT 'LastNameIdx'> IMPORT org.example.app.domain.Customer; SELECT * FROM /Customers x WHERE x.lastName = $1 LIMIT 10`
{sdg-name}'s Repository extension is careful not to create conflicting declarations when the OQL annotation extensions
are used in combination with the `@Query` annotation.
As another example, suppose you have a raw `@Query` annotated query method defined in your `CustomerRepository`,
as follows:
.CustomerRepository
====
[source,java]
----
public interface CustomerRepository extends GemfireRepository<Customer, Long> {
@Trace
@Limit(10)
@Hint("CustomerIdx")
@Import("org.example.app.domain.Customer")
@Query("<TRACE> <HINT 'ReputationIdx'> SELECT DISTINCT * FROM /Customers c WHERE c.reputation > $1 ORDER BY c.reputation DESC LIMIT 5")
List<Customer> findDistinctCustomersByReputationGreaterThanOrderByReputationDesc(Integer reputation);
}
----
====
The preceding query method results in the following OQL query:
`IMPORT org.example.app.domain.Customer; <TRACE> <HINT 'ReputationIdx'> SELECT DISTINCT * FROM /Customers x
WHERE x.reputation > $1 ORDER BY c.reputation DESC LIMIT 5`
The `@Limit(10)` annotation does not override the `LIMIT` explicitly defined in the raw query.
Also, the `@Hint("CustomerIdx")` annotation does not override the `HINT` explicitly defined in the raw query.
Finally, the `@Trace` annotation is redundant and has no additional effect.
[NOTE]
====
The `ReputationIdx` index is probably not the most sensible index, given the number of customers who may possibly have
the same value for their reputation, which reduces the effectiveness of the index. Please choose indexes and other
optimizations wisely, as an improper or poorly chosen index can have the opposite effect on your performance because
of the overhead in maintaining the index. The `ReputationIdx` was used only to serve the purpose of the example.
====
[[gemfire-repositories.queries.post-processing]]
== Query Post Processing
Thanks to using the Spring Data Repository abstraction, the query method convention for defining data store specific
queries (e.g. OQL) is easy and convenient. However, it is sometimes desirable to still want to inspect or even possibly
modify the query generated from the Repository query method.
Since 2.0.x, {sdg-name} includes the `o.s.d.gemfire.repository.query.QueryPostProcessor` functional interface.
The interface is loosely defined as follows:
.QueryPostProcessor
====
[source,java]
----
package org.springframework.data.gemfire.repository.query;
import org.springframework.core.Ordered;
import org.springframework.data.repository.Repository;
import org.springframework.data.repository.query.QueryMethod;
import ...;
@FunctionalInterface
interface QueryPostProcessor<T extends Repository, QUERY> extends Ordered {
QUERY postProcess(QueryMethod queryMethod, QUERY query, Object... arguments);
}
----
====
There are additional default methods provided that let you compose instances of `QueryPostProcessor` similar to how
https://docs.oracle.com/javase/8/docs/api/java/util/function/Function.html#compose-java.util.function.Function-[java.util.function.Function.andThen(:Function)]
and https://docs.oracle.com/javase/8/docs/api/java/util/function/Function.html#compose-java.util.function.Function-[java.util.function.Function.compose(:Function)]
work.
Additionally, the `QueryPostProcessor` interface implements the
{spring-framework-javadoc}/org/springframework/core/Ordered.html[`org.springframework.core.Ordered`] interface,
which is useful when multiple `QueryPostProcessors` are declared and registered in the Spring container and used to
create a pipeline of processing for a group of generated query method queries.
Finally, the `QueryPostProcessor` accepts type arguments corresponding to the type parameters, `T` and `QUERY`,
respectively. Type `T` extends the Spring Data Commons marker interface,
{spring-data-commons-javadoc}/org/springframework/data/repository/Repository.html[`org.springframework.data.repository.Repository`].
We discuss this further later in this section. All `QUERY` type parameter arguments in {sdg-name}'s case are of type
`java.lang.String`.
NOTE: It is useful to define the query as type `QUERY`, since this `QueryPostProcessor` interface may be ported to
Spring Data Commons and therefore must handle all forms of queries by different data stores (such as JPA, MongoDB,
or Redis).
You can implement this interface to receive a callback with the query that was generated from the application
`Repository` interface method when the method is called.
For example, you might want to log all queries from all application Repository interface definitions. You could do so
by using the following `QueryPostProcessor` implementation:
.LoggingQueryPostProcessor
====
[source,java]
----
package example;
import ...;
class LoggingQueryPostProcessor implements QueryPostProcessor<Repository, String> {
private Logger logger = Logger.getLogger("someLoggerName");
@Override
public String postProcess(QueryMethod queryMethod, String query, Object... arguments) {
String message = String.format("Executing query [%s] with arguments [%s]", query, Arrays.toString(arguments));
this.logger.info(message);
}
}
----
====
The `LoggingQueryPostProcessor` was typed to the Spring Data `org.springframework.data.repository.Repository`
marker interface, and, therefore, logs all application Repository interface query method generated queries.
You could limit the scope of this logging to queries only from certain types of application Repository interfaces,
such as, say, a `CustomerRepository`, as the following example shows:
.CustomerRepository
====
[source,java]
----
interface CustomerRepository extends CrudRepository<Customer, Long> {
Customer findByAccountNumber(String accountNumber);
List<Customer> findByLastNameLike(String lastName);
}
----
====
Then you could have typed the `LoggingQueryPostProcessor` specifically to the `CustomerRepository`, as follows:
.CustomerLoggingQueryPostProcessor
====
[source,java]
----
class LoggingQueryPostProcessor implements QueryPostProcessor<CustomerRepository, String> { .. }
----
====
As a result, only queries defined in the `CustomerRepository` interface, such as `findByAccountNumber`, are logged.
You might want to create a `QueryPostProcessor` for a specific query defined by a Repository query method. For example,
suppose you want to limit the OQL query generated from the `CustomerRepository.findByLastNameLike(:String)` query method
to only return five results along with ordering the `Customers` by `firstName`, in ascending order . To do so,
you can define a custom `QueryPostProcessor`, as the following example shows:
.OrderedLimitedCustomerByLastNameQueryPostProcessor
====
[source,java]
----
class OrderedLimitedCustomerByLastNameQueryPostProcessor implements QueryPostProcessor<CustomerRepository, String> {
private final int limit;
public OrderedLimitedCustomerByLastNameQueryPostProcessor(int limit) {
this.limit = limit;
}
@Override
public String postProcess(QueryMethod queryMethod, String query, Object... arguments) {
return "findByLastNameLike".equals(queryMethod.getName())
? query.trim()
.replace("SELECT", "SELECT DISTINCT")
.concat(" ORDER BY firstName ASC")
.concat(String.format(" LIMIT %d", this.limit))
: query;
}
}
----
====
While the preceding example works, you can achieve the same effect by using the Spring Data Repository convention
provided by {sdg-name}. For instance, the same query could be defined as follows:
.CustomerRepository using the convention
====
[source,java]
----
interface CustomerRepository extends CrudRepository<Customer, Long> {
@Limit(5)
List<Customer> findDistinctByLastNameLikeOrderByFirstNameDesc(String lastName);
}
----
====
However, if you do not have control over the application `CustomerRepository` interface definition,
then the `QueryPostProcessor` (that is, `OrderedLimitedCustomerByLastNameQueryPostProcessor`) is convenient.
If you want to ensure that the `LoggingQueryPostProcessor` always comes after the other application-defined
`QueryPostProcessors` that may have bean declared and registered in the Spring `ApplicationContext`, you can set
the `order` property by overriding the `o.s.core.Ordered.getOrder()` method, as the following example shows:
.Defining the `order` property
====
[source,java]
----
class LoggingQueryPostProcessor implements QueryPostProcessor<Repository, String> {
@Override
int getOrder() {
return 1;
}
}
class CustomerQueryPostProcessor implements QueryPostProcessor<CustomerRepository, String> {
@Override
int getOrder() {
return 0;
}
}
----
====
This ensures that you always see the effects of the post processing applied by other `QueryPostProcessors`
before the `LoggingQueryPostProcessor` logs the query.
You can define as many `QueryPostProcessors` in the Spring `ApplicationContext` as you like and apply them in any order,
to all or specific application Repository interfaces, and be as granular as you like by using the provided arguments
to the `postProcess(..)` method callback.

113
spring-data-geode-docs/src/docs/asciidoc/reference/samples.adoc Normal file
View File

@@ -0,0 +1,113 @@
[[samples]]
= Sample Applications
NOTE: Sample applications are now maintained in the
https://github.com/spring-projects/spring-gemfire-examples[Spring {data-store-name} Examples] repository.
The {sdg-name} project also includes one sample application. Named "`Hello World`", the sample application
demonstrates how to configure and use {data-store-name} inside a Spring application. At run time, the sample offers
a shell that lets you run various commands against the data grid. It provides an excellent
starting point for developers who are unfamiliar with the essential components or with Spring and {data-store-name} concepts.
The sample is bundled with the distribution and is Maven-based. You can import it into any
Maven-aware IDE (such as the https://spring.io/tools/sts[Spring Tool Suite]) or run them from the command-line.
[[samples:hello-world]]
== Hello World
The "`Hello World`" sample application demonstrates the core functionality of the {sdg-name} project.
It bootstraps {data-store-name}, configures it, executes arbitrary commands against the cache, and shuts it down
when the application exits. Multiple instances of the application can be started at the same time
and work together, sharing data without any user intervention.
.Running under Linux
NOTE: If you experience networking problems when starting {data-store-name} or the samples, try adding the following
system property `java.net.preferIPv4Stack=true` to the command line (for example, `-Djava.net.preferIPv4Stack=true`).
For an alternative (global) fix (especially on Ubuntu), see https://jira.spring.io/browse/SGF-28[SGF-28].
[[samples:hello-world:start-stop]]
=== Starting and Stopping the Sample
The "`Hello World`" sample application is designed as a stand-alone Java application. It features a `main` class that can be started
either from your IDE (in Eclipse or STS, through `Run As/Java Application`) or from the command line
through Maven with `mvn exec:java`. If the classpath is properly set, you can also use `java` directly on the resulting artifact.
To stop the sample, type `exit` at the command line or press `Ctrl+C` to stop the JVM and shutdown
the Spring container.
[[samples:hello-world:run]]
=== Using the Sample
Once started, the sample creates a shared data grid and lets you issue commands against it.
The output should resemble the following:
[source]
----
INFO: Created {data-store-name} Cache [Spring {data-store-name} World] v. X.Y.Z
INFO: Created new cache region [myWorld]
INFO: Member xxxxxx:50694/51611 connecting to region [myWorld]
Hello World!
Want to interact with the world ? ...
Supported commands are:
get <key> - retrieves an entry (by key) from the grid
put <key> <value> - puts a new entry into the grid
remove <key> - removes an entry (by key) from the grid
...
----
For example, to add new items to the grid, you can use the following commands:
[source]
----
-> Bold Section qName:emphasis level:5, chunks:[put 1 unu] attrs:[role:bold]
INFO: Added [1=unu] to the cache
null
-> Bold Section qName:emphasis level:5, chunks:[put 1 one] attrs:[role:bold]
INFO: Updated [1] from [unu] to [one]
unu
-> Bold Section qName:emphasis level:5, chunks:[size] attrs:[role:bold]
1
-> Bold Section qName:emphasis level:5, chunks:[put 2 two] attrs:[role:bold]
INFO: Added [2=two] to the cache
null
-> Bold Section qName:emphasis level:5, chunks:[size] attrs:[role:bold]
2
----
Multiple instances can be ran at the same time. Once started, the new VMs automatically see the existing region
and its information, as the following example shows:
[source]
----
INFO: Connected to Distributed System ['Spring {data-store-name} World'=xxxx:56218/49320@yyyyy]
Hello World!
...
-> Bold Section qName:emphasis level:5, chunks:[size] attrs:[role:bold]
2
-> Bold Section qName:emphasis level:5, chunks:[map] attrs:[role:bold]
[2=two] [1=one]
-> Bold Section qName:emphasis level:5, chunks:[query length = 3] attrs:[role:bold]
[one, two]
----
We encourage you to experiment with the example, start (and stop) as many instances as you want, and run various commands in one instance
and see how the others react. To preserve data, at least one instance needs to be alive all times. If all instances
are shutdown, the grid data is completely destroyed.
[[samples:hello-world:explained]]
=== Hello World Sample Explained
The "`Hello World`" sample uses both Spring XML and annotations for its configuration. The initial bootstrapping configuration is
`app-context.xml`, which includes the cache configuration defined in the `cache-context.xml` file
and performs classpath
https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-classpath-scanning[component scanning]
for Spring
https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-annotation-config[components].
The cache configuration defines the {data-store-name} cache, a region, and for illustrative purposes, a `CacheListener`
that acts as a logger.
The main beans are `HelloWorld` and `CommandProcessor`, which rely on the `GemfireTemplate` to interact with
the distributed fabric. Both classes use annotations to define their dependency and life-cycle callbacks.

71
spring-data-geode-docs/src/docs/asciidoc/reference/serialization.adoc Normal file
View File

@@ -0,0 +1,71 @@
[[serialization]]
= Working with {data-store-name} Serialization
To improve overall performance of the {data-store-name} In-memory Data Grid, {data-store-name} supports a dedicated
serialization protocol, called PDX, that is both faster and offers more compact results over standard Java serialization
in addition to working transparently across various language platforms (Java, C++, and .NET).
See {x-data-store-docs}/developing/data_serialization/PDX_Serialization_Features.html[PDX Serialization Features]
and {x-data-store-wiki}/PDX+Serialization+Internals[PDX Serialization Internals] for more details.
This chapter discusses the various ways in which {sdg-name} simplifies and improves {data-store-name}'s
custom serialization in Java.
[[serialization:wiring]]
== Wiring deserialized instances
It is fairly common for serialized objects to have transient data. Transient data is often dependent on the system
or environment where it lives at a certain point in time. For instance, a `DataSource` is environment specific.
Serializing such information is useless and potentially even dangerous, since it is local to a certain VM or machine.
For such cases, {sdg-name} offers a special {x-data-store-javadoc}/org/apache/geode/Instantiator.html[`Instantiator`]
that performs wiring for each new instance created by {data-store-name} during deserialization.
Through such a mechanism, you can rely on the Spring container to inject and manage certain dependencies, making it easy
to split transient from persistent data and have rich domain objects in a transparent manner.
Spring users might find this approach similar to that of {spring-framework-docs}/#aop-atconfigurable[`@Configurable`]).
The `WiringInstantiator` works similarly to `WiringDeclarableSupport`, trying to first locate a bean definition
as a wiring template and otherwise falling back to auto-wiring.
See the previous section (<<apis:declarable>>) for more details on wiring functionality.
To use the {sdg-acronym} `Instantiator`, declare it as a bean, as the following example shows:
[source,xml]
----
<bean id="instantiator" class="org.springframework.data.gemfire.serialization.WiringInstantiator">
<!-- DataSerializable type -->
<constructor-arg>org.pkg.SomeDataSerializableClass</constructor-arg>
<!-- type id -->
<constructor-arg>95</constructor-arg>
</bean>
----
During the Spring container startup, once it has been initialized, the `Instantiator`, by default, registers itself with
the {data-store-name} serialization system and performs wiring on all instances of `SomeDataSerializableClass` created
by {data-store-name} during deserialization.
[[serialization:instance-generator]]
== Auto-generating Custom `Instantiators`
For data intensive applications, a large number of instances might be created on each machine as data flows in.
{data-store-name} uses reflection to create new types, but, for some scenarios, this might prove to be expensive.
As always, it is good to perform profiling to quantify whether this is the case or not. For such cases, {sdg-name}
allows the automatic generation of `Instatiator` classes, which instantiate a new type (using the default constructor)
without the use of reflection. The following example shows how to create an instantiator:
[source,xml]
----
<bean id="instantiatorFactory" class="org.springframework.data.gemfire.serialization.InstantiatorFactoryBean">
<property name="customTypes">
<map>
<entry key="org.pkg.CustomTypeA" value="1025"/>
<entry key="org.pkg.CustomTypeB" value="1026"/>
</map>
</property>
</bean>
----
The preceding definition automatically generates two `Instantiators` for two classes (`CustomTypeA` and `CustomTypeB`)
and registers them with {data-store-name} under user ID `1025` and `1026`. The two `Instantiators` avoid the use of
reflection and create the instances directly through Java code.

255
spring-data-geode-docs/src/docs/asciidoc/reference/snapshot.adoc Normal file
View File

@@ -0,0 +1,255 @@
[[bootstrap:snapshot]]
= Configuring the Snapshot Service
{sdg-name} supports cache and Region snapshots by using
{x-data-store-docs}/managing/cache_snapshots/chapter_overview.html[{data-store-name}'s Snapshot Service].
The out-of-the-box Snapshot Service support offers several convenient features to simplify the use of {data-store-name}'s
{x-data-store-javadoc}/org/apache/geode/cache/snapshot/CacheSnapshotService.html[Cache]
and {x-data-store-javadoc}/org/apache/geode/cache/snapshot/RegionSnapshotService.html[Region]
Snapshot Service APIs.
As the {x-data-store-docs}/managing/cache_snapshots/chapter_overview.html[{data-store-name} documentation] explains,
snapshots let you save and subsequently reload the cached data later, which can be useful for moving data between
environments, such as from production to a staging or test environment in order to reproduce data-related issues
in a controlled context. You can combine {sdg-name}'s Snapshot Service support
with https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-definition-profiles[Spring's bean definition profiles]
to load snapshot data specific to the environment as necessary.
{sdg-name}'s support for {data-store-name}'s Snapshot Service begins with the `<gfe-data:snapshot-service>` element
from the `<gfe-data>` XML namespace.
For example, you can define cache-wide snapshots to be loaded as well as saved by using a couple of snapshot imports
and a data export definition, as follows:
[source,xml]
----
<gfe-data:snapshot-service id="gemfireCacheSnapshotService">
<gfe-data:snapshot-import location="/absolute/filesystem/path/to/import/fileOne.snapshot"/>
<gfe-data:snapshot-import location="relative/filesystem/path/to/import/fileTwo.snapshot"/>
<gfe-data:snapshot-export
location="/absolute/or/relative/filesystem/path/to/export/directory"/>
</gfe-data:snapshot-service>
----
You can define as many imports and exports as you like. You can define only imports or only exports. The file locations
and directory paths can be absolute or relative to the {sdg-name} application, which is the JVM process's
working directory.
The preceding example is pretty simple, and the Snapshot Service defined in this case refers to the {data-store-name}
cache instance with the default name of `gemfireCache` (as described in <<bootstrap:cache>>). If you name your cache
bean definition something other than the default, you can use the `cache-ref` attribute to refer to the cache bean
by name, as follows:
[source,xml]
----
<gfe:cache id="myCache"/>
...
<gfe-data:snapshot-service id="mySnapshotService" cache-ref="myCache">
...
</gfe-data:snapshot-service>
----
You can also define a Snapshot Service for a particular Region by specifying the `region-ref` attribute, as follows:
[source,xml]
----
<gfe:partitioned-region id="Example" persistent="false" .../>
...
<gfe-data:snapshot-service id="gemfireCacheRegionSnapshotService" region-ref="Example">
<gfe-data:snapshot-import location="relative/path/to/import/example.snapshot/>
<gfe-data:snapshot-export location="/absolute/path/to/export/example.snapshot/>
</gfe-data:snapshot-service>
----
When the `region-ref` attribute is specified, {sdg-name}'s `SnapshotServiceFactoryBean` resolves the `region-ref`
attribute value to a Region bean defined in the Spring container and creates a
{x-data-store-javadoc}/org/apache/geode/cache/snapshot/RegionSnapshotService.html[`RegionSnapshotService`].
The snapshot import and export definitions function the same way. However, the `location` must refer to a file
on an export.
NOTE: {data-store-name} is strict about imported snapshot files actually existing before they are referenced.
For exports, {data-store-name} creates the snapshot file. If the snapshot file for export already exists,
the data is overwritten.
TIP: {sdg-name} includes a `suppress-import-on-init` attribute on the `<gfe-data:snapshot-service>` element
to suppress the configured Snapshot Service from trying to import data into the cache or Region on initialization.
Doing so is useful, for example, when data exported from one Region is used to feed the import of another Region.
[[bootstrap:snapshot:location]]
== Snapshot Location
With the cache-based Snapshot Service
(that is, a {x-data-store-javadoc}/org/apache/geode/cache/snapshot/CacheSnapshotService.html[`CacheSnapshotService`])
you would typically pass it a directory containing all the snapshot files to load rather than individual snapshot files,
as the overloaded {x-data-store-javadoc}/org/apache/geode/cache/snapshot/CacheSnapshotService.html#load-java.io.File-org.apache.geode.cache.snapshot.SnapshotOptions.SnapshotFormat[`load`]
method in the `CacheSnapshotService` API indicates.
NOTE: Of course, you can use the overloaded `load(:File[], :SnapshotFormat, :SnapshotOptions)` method to get specific
about which snapshot files to load into the {data-store-name} cache.
However, {sdg-name} recognizes that a typical developer workflow might be to extract and export data
from one environment into several snapshot files, zip all of them up, and then conveniently move the zip file
to another environment for import.
Therefore, {sdg-name} lets you specify a jar or zip file on import for a `cache`-based Snapshot Service, as follows:
[source,xml]
----
<gfe-data:snapshot-service id="cacheBasedSnapshotService" cache-ref="gemfireCache">
<gfe-data:snapshot-import location="/path/to/snapshots.zip"/>
</gfe-data:snapshot-service>
----
{sdg-name} conveniently extracts the provided zip file and treats it as a directory import (load).
[[bootstrap:snapshot:filters]]
== Snapshot Filters
The real power of defining multiple snapshot imports and exports is realized through the use of snapshot filters.
Snapshot filters implement {data-store-name}'s {x-data-store-javadoc}/org/apache/geode/cache/snapshot/SnapshotFilter.html[`SnapshotFilter`] interface
and are used to filter Region entries for inclusion into the Region on import and for inclusion into the snapshot
on export.
{sdg-name} lets you use snapshot filters on import and export by using the `filter-ref` attribute or an anonymous,
nested bean definition, as the following example shows:
[source,xml]
----
<gfe:cache/>
<gfe:partitioned-region id="Admins" persistent="false"/>
<gfe:partitioned-region id="Guests" persistent="false"/>
<bean id="activeUsersFilter" class="example.gemfire.snapshot.filter.ActiveUsersFilter/>
<gfe-data:snapshot-service id="adminsSnapshotService" region-ref="Admins">
<gfe-data:snapshot-import location="/path/to/import/users.snapshot">
<bean class="example.gemfire.snapshot.filter.AdminsFilter/>
</gfe-data:snapshot-import>
<gfe-data:snapshot-export location="/path/to/export/active/admins.snapshot" filter-ref="activeUsersFilter"/>
</gfe-data:snapshot-service>
<gfe-data:snapshot-service id="guestsSnapshotService" region-ref="Guests">
<gfe-data:snapshot-import location="/path/to/import/users.snapshot">
<bean class="example.gemfire.snapshot.filter.GuestsFilter/>
</gfe-data:snapshot-import>
<gfe-data:snapshot-export location="/path/to/export/active/guests.snapshot" filter-ref="activeUsersFilter"/>
</gfe-data:snapshot-service>
----
In addition, you can express more complex snapshot filters by using the `ComposableSnapshotFilter` class.
This class implements {data-store-name}'s {x-data-store-javadoc}/org/apache/geode/cache/snapshot/SnapshotFilter.html[SnapshotFilter] interface
as well as the https://en.wikipedia.org/wiki/Composite_pattern[Composite] software design pattern.
In a nutshell, the https://en.wikipedia.org/wiki/Composite_pattern[Composite] software design pattern lets you
compose multiple objects of the same type and treat the aggregate as single instance of the object type -- a
powerful and useful abstraction.
`ComposableSnapshotFilter` has two factory methods, `and` and `or`. They let you logically combine individual snapshot
filters using the AND and OR logical operators, respectively. The factory methods take a list of `SnapshotFilters`.
The following example shows a definition for a `ComposableSnapshotFilter`:
[source,xml]
----
<bean id="activeUsersSinceFilter" class="org.springframework.data.gemfire.snapshot.filter.ComposableSnapshotFilter"
factory-method="and">
<constructor-arg index="0">
<list>
<bean class="org.example.app.gemfire.snapshot.filter.ActiveUsersFilter"/>
<bean class="org.example.app.gemfire.snapshot.filter.UsersSinceFilter"
p:since="2015-01-01"/>
</list>
</constructor-arg>
</bean>
----
You could then go on to combine the `activesUsersSinceFilter` with another filter by using `or`, as follows:
[source,xml]
----
<bean id="covertOrActiveUsersSinceFilter" class="org.springframework.data.gemfire.snapshot.filter.ComposableSnapshotFilter"
factory-method="or">
<constructor-arg index="0">
<list>
<ref bean="activeUsersSinceFilter"/>
<bean class="example.gemfire.snapshot.filter.CovertUsersFilter"/>
</list>
</constructor-arg>
</bean>
----
[[bootstrap::snapshot::events]]
== Snapshot Events
By default, {sdg-name} uses {data-store-name}'s Snapshot Services on startup to import data and on shutdown
to export data. However, you may want to trigger periodic, event-based snapshots, for either import or export,
from within your Spring application.
For this purpose, {sdg-name} defines two additional Spring application events, extending Spring's
https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/context/ApplicationEvent.html[`ApplicationEvent`]
class for imports and exports, respectively: `ImportSnapshotApplicationEvent` and `ExportSnapshotApplicationEvent`.
The two application events can be targeted for the entire {data-store-name} cache or for individual {data-store-name}
Regions. The constructors in these classes accept an optional Region pathname (such as `/Example`) as well as zero
or more `SnapshotMetadata` instances.
The array of `SnapshotMetadata` overrides the snapshot metadata defined by `<gfe-data:snapshot-import>`
and `<gfe-data:snapshot-export>` sub-elements, which are used in cases where snapshot application events do not
explicitly provide `SnapshotMetadata`. Each individual `SnapshotMetadata` instance can define its own `location`
and `filters` properties.
All snapshot service beans defined in the Spring `ApplicationContext` receive import and export snapshot
application events. However, only matching Snapshot Service beans process import and export events.
A Region-based `[Import|Export]SnapshotApplicationEvent` matches if the Snapshot Service bean defined
is a `RegionSnapshotService` and its Region reference (as determined by the `region-ref` attribute) matches
the Region's pathname, as specified by the snapshot application event.
A Cache-based `[Import|Export]SnapshotApplicationEvent` (that is, a snapshot application event without a Region pathname)
triggers all Snapshot Service beans, including any `RegionSnapshotService` beans, to perform either an import or export,
respectively.
You can use Spring's
{spring-framework-javadoc}/org/springframework/context/ApplicationEventPublisher.html[`ApplicationEventPublisher`]
interface to fire import and export snapshot application events from your application as follows:
[source,java]
----
@Component
public class ExampleApplicationComponent {
@Autowired
private ApplicationEventPublisher eventPublisher;
@Resource(name = "Example")
private Region<?, ?> example;
public void someMethod() {
...
File dataSnapshot = new File(System.getProperty("user.dir"), "/path/to/export/data.snapshot");
SnapshotFilter myFilter = ...;
SnapshotMetadata exportSnapshotMetadata =
new SnapshotMetadata(dataSnapshot, myFilter, null);
ExportSnapshotApplicationEvent exportSnapshotEvent =
new ExportSnapshotApplicationEvent(this, example.getFullPath(), exportSnapshotMetadata)
eventPublisher.publishEvent(exportSnapshotEvent);
...
}
}
----
In the preceding example, only the `/Example` Region's Snapshot Service bean picks up and handles the export event,
saving the filtered, "`/Example`" Region's data to the `data.snapshot` file in a sub-directory of the application's
working directory.
Using the Spring application events and messaging subsystem is a good way to keep your application loosely coupled.
You can also use Spring's {spring-framework-docs}/#scheduling-task-scheduler[Scheduling] services to fire
snapshot application events on a periodic basis.

201
spring-data-geode-docs/src/main/resources/license.txt Normal file
View File

@@ -0,0 +1,201 @@
Apache License
Version 2.0, January 2004
https://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
https://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

56
spring-data-geode-docs/src/main/resources/notice.txt Normal file
View File

@@ -0,0 +1,56 @@
Spring Data for Apache Geode 3.0 M6 (2022.0.0)
== NOTICE file corresponding to section 4 d of the Apache License, ==
== Version 2.0, for the Spring Framework distribution. ==
======================================================================
This product includes software developed by
the Apache Software Foundation (https://www.apache.org).
The end-user documentation included with a redistribution, if any,
must include the following acknowledgement:
"This product includes software developed by the Spring Framework
Project (https://www.springframework.org)."
Alternately, this acknowledgement may appear in the software itself,
if and wherever such third-party acknowledgements normally appear.
The names "Spring", "Spring Framework", and "Spring GemFire" must
not be used to endorse or promote products derived from this
software without prior written permission. For written permission,
please contact enquiries@springsource.com.
<<<<<<< HEAD
=======
>>>>>>> Prepare 3.0 M1 (2022.0.0).

24
spring-data-geode-docs/src/main/resources/readme.txt Normal file
View File

@@ -0,0 +1,24 @@
SPRING DATA GEMFIRE
-------------------
https://www.springsource.org/spring-gemfire
1. INTRODUCTION
Spring Data GemFire started as a top level Spring project, formerly known as Spring GemFire,
and is now a component of the Spring Data project. The project's purpose is to make it easier to
build Spring-powered highly scalable applications using vFabric GemFire as distributed data management platform.
2. RELEASE NOTES
This release comes with complete reference documentation. For further
details, consult the provided javadoc for specific packages and classes.
3. GETTING STARTED
Please see the reference documentation at https://spring.io/projects/spring-data-geode
and the Spring GemFire Examples at https://github.com/SpringSource/spring-gemfire-examples
ADDITIONAL RESOURCES
Spring Data GemFire Homepage : https://www.springsource.org/spring-gemfire
VMware vFabric GemFire Documentation: https://www.vmware.com/products/application-platform/vfabric-gemfire/overview.html
VMware vFabric GemFire product page: https://www.vmware.com/products/application-platform/vfabric-gemfire