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...
https://spring.io/blog/2017/11/27/spring-data-ingalls-sr9-an d-kay-sr2-released 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... *SPRING-GEODE TIP:* 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... @Region("Customers") 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... @SpringBootApplication @ClientCacheApplication @EnableEntityDefinedRegions(basePackageClasses = Customer.class, clientRegionShortcut = ClientRegionShortcut.LOCAL) @EnableGemfireRepositories(basePackageClasses = CustomerRepository.class) @EnableIndexing @EnablePdx //@EnableClusterConfiguration(useHttp = true) public class SpringBootApacheGeodeClientApplication { public static void main(String[] args) { SpringApplication.run(SpringBootApacheGeodeClientApplication.class, 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 default. 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 the @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 restarted. SDG is very careful not to stomp on your existing (sever/cluster) configuration, hopefully for obvious reasons. If the Region already exists, SDG will not attempt to create it. I will be posting more examples like this over time so that everyone here will become familiar with the features and conveniences that SDG is adding. You find details on the complete example ( https://github.com/ jxblum/simple-spring-geode-application) in *GitHub* [11]. Happy coding! -- -John [1] https://docs.spring.io/spring/docs/current/spring-framew ork-reference/integration.html#cache [2] http://geode.apache.org/docs/guide/12/developing/continu ous_querying/chapter_overview.html [3] https://github.com/jxblum/contacts-application/tree/mast er/continuous-query-example [4] https://docs.spring.io/spring-data/geode/docs/current/re ference/html/#bootstrap-annotation-config-regions [5] https://docs.spring.io/spring-data/geode/docs/current/re ference/html/#bootstrap-annotation-config-caching [6] https://docs.spring.io/spring/docs/current/spring-framew ork-reference/integration.html#cache-jsr-107 [7] http://geode.apache.org/docs/guide/12/managing/region_co mpression/region_compression.html [8] https://docs.spring.io/spring-data/geode/docs/current/re ference/html/#bootstrap-annotation-config-region-compression [9] https://docs.spring.io/spring-data/geode/docs/2.0.2.RELE ASE/changelog.txt [10] http://geode.apache.org/docs/guide/12/configuring/clust er_config/gfsh_persist.html [11] https://github.com/jxblum/simple-spring-geode-application
