Subject: [ANNOUNCE] Spring Data Geode 2.0.2.RELEASE (Kay SR2) Available!

Greetings Apache Geode Community-

It is my pleasure to announce the availability of *Spring Data* *Kay
SR2* (*Service
Release* 2) which includes *Spring Data Geode* *2.0.2.RELEASE*.  The
official release announcement is here...

Unfortunately, we missed the announce for the first service release of *Kay*,
which occurred back on October 27th; my apologies.

So, in both *Kay SR1 + SR2*, you will find the follow improvements...
* Better, more reliable integration between *Spring's Cache Abstraction* [1]
and *Spring* container initialization (particularly in the context of
proxies) with Geode CQ [2].  I have even have a complete example here [3]
(README in-progress).

* In both *Entity-defined* as well as *Caching-defined* *Regions*, I have
enabled the ability to configure the ClientRegionShortcut for client-side
generated Regions and RegionShortcut for server-side generated Regions.
You can learn more about *Entity-defined Regions* [4] and *Caching-defined
Regions* [5] by following the links.

* In addition to *Spring's Caching Annotations* [6] I have also added
support for JSR-107 *JCache* API Annotations in SDG's *Caching-defined
Regions*.  That means, if you used any of the JSR-107 annotations in your
application service components and declared the SDG
@EnableCachingDefinedRegions annotation on your *Spring Boot* @Configuration
class, then you can define cache client Regions from the "caches"
identified in your use of JSR-107 annotations.

* I added Annotation support for configuring Apache Geode Region
Compression [7] using the @EnableCompression annotation; see docs [8] for
more details.  By default, it just enables the Google Snappy Compressor,
provided by Apache Geode OOTB.
Several other little enhancements were made and help to improve the overall
development experience when using Apache Geode, especially in a *Spring*
context.  See the *changelog* [9] for a complete list of changes in *Kay
SR1 + SR2*.
Finally, I leave you with a...

Let's say you want to create a simple *Spring Boot*, ClientCache
application to store and manage customer data.  It is as simple as this...
// Define Customer...

public class Customer {

   private Long id;

   @Indexed(from = "/Customers")
   private String name;

// Define a Repository to persist and query Customers

public interface CustomerRepository extends CrudRepository<Customer, Long> {
// Finally, create your *Spring Boot* application & run everything...

@EnableEntityDefinedRegions(basePackageClasses = Customer.class,
clientRegionShortcut = ClientRegionShortcut.LOCAL)
@EnableGemfireRepositories(basePackageClasses = CustomerRepository.class)
//@EnableClusterConfiguration(useHttp = true)
public class SpringBootApacheGeodeClientApplication {

   public static void main(String[] args) {,

I challenge anyone to find any boilerplate code in this example application
(other than the basic, yet essential application/feature bootstrapping).

No longer do you need boilerplate code to configure and create a
*ClientCache*, *Pool*, *Regions*, *Indexes*, PDX, etc or to perform basic
CRUD and simple (OQL) Queries.

As am application developer, you can remain completely *focused* and
*committed* to your application business requirements and logic, and let
*SDG* worry about the plumbing.

Because, I am "initially" using a ClientRegionShortcut.LOCAL, this "
*ClientCache*" application runs properly, all by itself, without the need
to start a server.  This is ideal when you are rapidly prototyping your
application and want to iterate (DEV-TEST) quickly!

However, it is a simple matter to also convert this application to use
Apache Geode's client/server topology as well... simply remove the
configuration for the clientRegionShortcut attribute in the
@EnableEntityDefinedRegions annotation.

By default, a client Region is set to PROXY and all Region ops will be sent
to a server using the *ClientCache* "DEFAULT" *Pool*, which is configured
to connect to a server running on localhost, listening on port 40404, by

You can start 1 or more server(s) using *Gfsh* and optionally configure
them either using *Gfsh* or SDG.  You choose!

While it is likely that you will use *Gfsh* to script your configuration of
the server(s) in the cluster, there is nothing that helps you on the
client, other than SDG, of course!  Imagine if you have 100s of Regions to
configure, and not only Regions, but Indexes, Disk Stores, and other schema
objects as well.

While it is appropriate (and even "*recommended*") to use *Gfsh* to script
your final production configuration deployment, during your "building" and
"testing' phases, personally, I prefer to use the new SDG
@EnableClusterConfiguration(useHttp = true) annotation.  This annotation
will push all *Entity-defined Region* configuration up to the server(s) in
your cluster, from the client app.  Not only will it create corresponding
server-side (PARTITION) Regions for all the client (PROXY) Regions, it will
also create Indexes from your application domain object @Indexed fields on
the server(s) as well.

NOTE: You need a full installation of Apache Geode on the servers to use
@EnableClusterConfiguration feature.

And, if that were not enough, the @EnableClusterConfiguration annotation
performs the cluster server(s) modification in such a way that Apache
Geode's Cluster Configuration service [10] will remember these changes.
Therefore, if you had new nodes, those nodes will have a consistent
configuration.  Additionally, if you bounce your entire cluster, or the
cluster goes down, it will come back up with the same configuration when

SDG is very careful not to stomp on your existing (sever/cluster)