Consider removing JSR-107 - JCache API dependency from starters about spring-boot-data-geode

[snicoll]

Comparing Redis to GemFire/Geode is like comparing house cats to tigers.

I wasn't doing that. I was comparing one store with another and how they behave with regards to caching.

Essentially, I want to enable users with as many "auto-configured" capabilities OOTB as possible, so that they can get up and running as quickly, and easily, and reliably as possible, for whatever their application concern(s) or UCs might be.

I have no problem with that as long as the signal that the user wants to use the feature is explicit enough. There are various mechanism that can be used, the most common being the presence of a given library on the classpath. Caching is quite different here as most providers can be used for caching and something else.

Spring Boot for Apache Geode's (SBDG) "auto-configuration" is also quite a bit more extensive then any other SD module for that matter

I wasn't comparing this project with a "regular" SpringData module either. I am merely reporting that, from a Spring Boot perspective, enabling features without proper signal from the user is something we try to avoid as much as possible.

[jxblum]

JSR-107, JCache API is a dependency required by SDG at present. SDG needs to be refactored to not require the JCache libs, by default, especially if the JCache libs and API are not present in the user's application classpath.

See SGF-808 for more details.

[snicoll]

Thanks for the feedback.

In the same topic, I am also wondering why the cache infrastructure is bootstrapped by default? In a typical Spring Boot app, caching does not happen unless you add @EnableCaching to your app. Given the starter covers several different use cases, can you please explain why this one works differently (i.e. if you add spring data redis, you don't get caching unless you ask for it).

[jxblum]

Regarding "auto-configuration" for caching, enabling Apache Geode (or Pivotal GemFire) to be a caching provider in Spring's Cache Abstraction...

Well, it fundamentally boils down to, we want users to:

1. Move from Open Source (Apache Geode) to Commercial (Pivotal Cloud Cache (PCC)), and...
2. Move from Non-Managed environments (standalone Apache Geode clusters) to Managed environments (Pivotal CloudFoundry using PCC), with...
3. With very little to no code or configuration changes.

NOTE: It also be possible and very easy to move back again, in the opposite direction.

And... Look-Aside Caching is the primary UC for PCC.

It is far simpler for a user to start annotating his/her @Service or DAO methods with caching annotations when needed, without having to (remember to) explicitly "enable" it. It does not add anymore overhead to do so.

But more importantly, Caching (in all it's glorious forms and uses) is also a precursor to app modernization where the users eventually go down the path of SOR (looking to replace the legacy data store completely), Event Stream Processing and finally, to Distributed Compute patterns.

It is actually, quite a bit more involved then what I just described above, but we'll leave it at that for now. Just know, most of which has transpired (thinking) has happened over the last 3 years.

Comparing Redis to GemFire/Geode is like comparing house cats to tigers. They're not really even the same animal and have significantly different UCs and problems that each solves quite well.

Essentially, I want to enable users with as many "auto-configured" capabilities OOTB as possible, so that they can get up and running as quickly, and easily, and reliably as possible, for whatever their application concern(s) or UCs might be.

As such, Spring Boot for Apache Geode's (SBDG) "auto-configuration" is also quite a bit more extensive then any other SD module for that matter as well, including, but not limited to the following:

1. Caching (which includes... Look-Aside Caching, Inline Caching, Near Caching, and soon... Multi-Site)
2. System of Record; SOR (using SD Repositories)
3. Distributed Compute (Functions)
4. Real-time, Event Stream Processing (CQ)
5. Security (Auth & TLS)
6. (HTTP) Session state caching
7. Serialization
8. etc...

It would be a mistake to think SBDG is just "auto-configuration" for Spring Data Geode.

Finally, I was also very careful in my auto-configuration, that if a user prefers to use another caching provider (e.g. Redis), then SBDG's Caching auto-configuration very nicely and quietly backs away.

Anyway, FWIW.

[jxblum]

Also see DATAGEODE-225.

[jxblum]

@snicoll - Understood.

[jxblum]

1 more thing regarding your response to my comments above:

1. From my perspective, I have sent the proper signals, or simply, have properly communicated what SBDG gives you OOTB, i.e. what auto-configuration is applied by default in both the README as well as the Introduction in the Reference Guide.

2. Just a friendly reminder, I have also taken steps (for example, this and this) to ensure that SBDG quietly and properly backs away when users have expressed their "explicit interests" in configuration, e.g. like which provider they want to use for caching. Furthermore, this would only be a concern when a user has multiple caching providers (e.g. Apache Geode & Redis) on the application classpath in the first place.

3. Finally, I also include a section in the Appendix that explains how a user might disable any Auto-Configuration applied by SBDG OOTB, by default.

Let me know if you have additional concerns.

[jxblum]

Final comment regarding this ticket...

While Spring Boot must properly account for every single technology (e.g. Redis, MongoDB, Hazelcast, this and that) that Boot integrates with, and that applies to a particular application concern (e.g. caching, or persistence using Spring Data Repositories, or whatever), SBDG does NOT have that restriction. Therefore, it may deviate slightly from the "conventions" or "opinions" of Spring Boot, itself. Personally, I think this is ok, and very much the intent of any project that would extend Spring Boot core (e.g. like SBDG) with features very specific to the underlying technology to fully and properly leverage the capabilities of the underlying technology. I do agree that those should be properly called out and documented, which I believe in SBDG's case, they are.

The fact of the matter is, SBDG is solely based on Apache Geode and Pivotal GemFire. Additionally, both Apache Geode and Pivotal GemFire are far more capable than many other (seemingly) comparable solutions, and therefore may apply to multiple application concerns simultaneously. As such, and as stated previously, SBDG makes as many application concerns as easy, and as quick and reliable to solve as possible, OOTB, with minimal fuss and configuration, which in Apache Geode and Pivotal GemFire's case, is especially easy to get wrong, hence the real value add of Spring Boot here, when applied to GemFire/Geode... being opinionated about how these technologies should be applied to the application.