This is a prototype of the restoration of Ehcache 3 support to Spring Boot. Ehcache uses Gradle feature variants (with appropriate capabilities) to model the split "Jakarta/Java EE" landscape. These are exposed in Maven as artifacts with 'jakarta' classifiers with appropriate optional dependencies. I've therefore implemented a solution to #29298 as a prerequisite here.
Currently this is depending on an alpha release of Ehcache 3.10, hence it's only a draft PR, but I wanted to get this out there for two reasons:
1. To confirm the acceptability of the classifier/feature variant approach for Jakarta support.
2. To understand the need for the ehcache-transactions module. The transactions module allows Ehcache instances to be exposed as XA resources and participate in 2PC managed by a JTA transaction manager. It's not clear to me how this relates to Springs caching support - I'm not sure how or why a user would need this dependency in a Spring (Boot) context.
Comment From: pivotal-cla
@chrisdennis Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.
Comment From: wilkinsona
Thanks, @chrisdennis.
I've therefore implemented a solution to https://github.com/spring-projects/spring-boot/issues/29298 as a prerequisite here.
Thanks for this. Unfortunately, it doesn't quite meet the requirements that we have for some of Kafka's modules. I implemented something earlier this year which should work for both cases, I just haven't had a chance to merge it yet.
To confirm the acceptability of the classifier/feature variant approach for Jakarta support
I don't think we have any dependencies that have taken this approach just yet, but I don't think it'll be a problem.
To understand the need for the ehcache-transactions module
Spring Boot supports JTA-based transaction coordination either by retrieving the UserTransaction and TransactionManager from JNDI when deployed as a war file in an application server, or via integration of a third-party transaction manager such as Narayana. We need to position Spring Boot 3.0 such that this will work in both cases with Jakarta EE 9. That should include cases where a user wants to enlist their cache as a resource.
Comment From: chrisdennis
@pivotal-cla This is an Obvious Fix
This reinstates previously existing code and introduces no new IP.
Comment From: wilkinsona
@chrisdennis You’ll need to sign the CLA, I’m afraid. The changes proposed here are not considered to be obvious as they will result in a change in functionality.
Comment From: chrisdennis
@wilkinsona no problem... I figured I would see what you guys thought before I went ahead and engaged with the bureaucracy on this end.
FYI: the alpha release referenced here is likely very close to what will become the 3.10.0 GA release. That should happen next week. Once I have that out I'll update the deps here and remove the draft status from this PR.
Comment From: pivotal-cla
@chrisdennis Thank you for signing the Contributor License Agreement!
Comment From: chrisdennis
Do you prefer a separate commit for review changes, or a force push?
Comment From: wilkinsona
Either's fine. Thank you. We'll squash multiple commits into one as part of merging so a force-push is probably slightly easier to process.
Comment From: snicoll
@chrisdennis thank you for the follow-up and for making your first contribution to Spring Boot.