Another great release from the Spring world!! --Udo
On Mon, Nov 27, 2017 at 11:39 PM, John Blum <jb...@pivotal.io> wrote: > 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 > -- Kindest Regards ----------------------------- *Udo Kohlmeyer* | *Pivotal* ukohlme...@pivotal.io <http://www.gopivotal.com/> www.pivotal.io
