Get ahead
VMware offers training and certification to turbo-charge your progress.
Learn moreI apologize to both the Spring and Apache Geode communities for the delay, relative to the Apache Geode M3 release announcement, but I am very excited and pleased to follow that with the release of Spring Data for Apache Geode 1.0.0-incubating.M3.
You can get the bits from Maven Central by including the following dependency in either your application Maven or Gradle build files ...
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-geode</artifactId>
<version>1.0.0.APACHE-GEODE-INCUBATING-M3</version>
</dependency>
compile 'org.springframework.data:spring-data-geode:1.0.0.APACHE-GEODE-INCUBATING-M3'
Including the spring-data-geode
dependency will transitively pull in all required Apache Geode artifacts so you can start building Spring applications that use Apache Geode today.
While not much functionally changed between Apache Geode M2 and M3 (mainly bug fixes), many things did change in Spring Data Geode. One key feature stands above all the rest.
Because the focus of Apache Geode (and by extension, Pivotal GemFire) has always been to provide enough functional breadth and flexibility to address a wide array of complex customer requirements and use cases (click "Use Cases"), it has made it difficult for users to get up and running as quickly, and as easily as possible. And, though it has much stronger consistency guarantees, and often times, better performance, it is hard to compete with the out-of-box experience when using alternative, comparable solutions.
To gain more insight into the problem along with how we are focused on resolving it for Apache Geode and Pivotal GemFire, checkout my talk in the August, Apache Geode Clubhouse Meeting.
The problem has been rooted in the fact that Apache Geode has lacked an opinionated and consistent programming/configuration model, particularly for application development. So really, we don't need to look any further than the Spring Framework. However, that still leaves "opinion".
Once again, Spring gives us Spring Boot, and what a beautiful piece of engineering it is, so elegant, so simple. And, as you will see below, it has truly been an inspiration for the work on Spring Data Geode.
In the past, Spring developers had to configure Geode with either XML, or Java config, and then use a bootstrapping mechanism, like Gfsh, or Spring Boot, to get up and running. This has even been demonstrated in the guides. Neither one was really a significant advantage over the other until now.
From this milestone release onward, Spring Data Geode will include a new set of annotations, very similar in form/function, and complimentary to, Spring Boot annotations, but specifically for SD/Apache Geode, with 1 simple goal in mind...
Simply the out-of-box experience in order to get users up and running as quickly and easily as possible
So, let's take our XML and Java config example and do it one more time...
@SpringBootApplication
@PeerCacheApplication
@WithReplicateRegions("myDistributedMap")
public class ExampleApplication implements CommandLineRunner {
public static void main(String[] args) {
SpringApplication.run(ExampleApplication.class, args);
}
@Resource(name = "myDistributedMap")
private Region<String, String> myDistributedMap;
@Override
public void run(String... strings) throws Exception {
assertThat(myDistributedMap.put("key", "value")).isNull();
assertThat(myDistributedMap.get("key")).isEqualTo("value");
assertThat(myDistributedMap.putIfAbsent("somekey", "somevalue")).isNull();
assertThat(myDistributedMap.replace("key", "value", "newvalue")).isTrue();
}
}
Pretty easy. This example is rather simplistic, but you can probably imagine some application configurations (for example; just follow the hierarchy) becoming pretty involved rather quickly.
This is a teaser for now, so stay tuned for more.
There will be many different annotations to address all the unique concerns in a consistent and robust way, providing out-of-box defaults along with many convenient, "enabling" features. Many of the details of this new Annotation configuration model are still a work in progress, such as proper examples and documentation.
In the interim, I have started the beginnings of a reference implementation that will showcase many of the features and functionality of using Spring and Apache Geode together (like the new Annotation configuration model).
Look for more communications from us down the road soon.
As always, feedback is most welcomed, and you can reach out to us in JIRA or on StackOverflow.
Thanks all!