Support for the JCache API (JSR-107)

[ebruchez]

We are currently using Ehcache 2.x as cache. We have considered upgrading to Ehcache 3.x (#3404), which is not hard to do, except that the replication setup now requires a separate Terracotta server. We didn't want to change this right away for questions of time and also impact on existing users, who would have to do more work to upgrade. Since Ehcache 2.x still has the occasional update, we have accepted to defer upgrading to Ehcache 3.x.

Now using the JCache API could provide a smooth migration path:

• rewrite our code against the API
• include https://github.com/ehcache/ehcache-jcache so things wtill work with Ehcache 2
• possibly provide Ehcache 3.x as provider out of the box

This would allow users to:

• use Ehcache 3.x by default
• keep/choose Ehcache 2.x without Terracotta server if they wish to
• use Ehcache 3.x with Terracotta server
• use any other caching solution that supports the JCache API

+1 from customer

[ebruchez]

Uses of Ehcache:

• AssetsAggregator
• Caches
• EhcacheStateStore

Uses are basic:

• new EhElement()
• new CacheManager
• cacheManager.getCache()
• cache.put()
• cache.get()
• cache.remove()
• cache.getCacheConfiguration.getMaxEntriesLocalHeap
• cache.getStatistics.getLocalHeapSize

[ebruchez]

Also the use of JCache allows more easily integrating into environments like Kubernetes.

[ebruchez]

Looking at JCache doc, in particular with Ehcache 2 and Ehcache 3.

Right now, we hardcode Ehcache 2 support. We load the config from oxf:/config/ehcache.xml, through our own resource manager.

Using JCache with Ehcache 2, getCacheManager() loads an ehcache.xml using classloaders (it seems you could also use getCacheManager("foo") but that doesn't appear to even compile). It doesn't seem that we can get backward compatibility while keeping the file location.

Using JCache with Ehcache 3, you can pass getClass.getResource("/config/ehcache3.xml").toURI, which would bring some compatibility of the file location, but would not allow all oxf:/ resource support. In addition, the configuration is of course different from Ehcache 2's.

If we want to keep full backward compatibility, we'd need either:

1. to have an option to enable the cache provider type: built-in (Ehcache 2), or JCache
2. or to try JCache, and if a provider is available use that, or else fall back to built-in (with the risk that there would be a provider in the classpath? can that happen?)

[ebruchez]

If we provide two types of caches, we need some kind of abstraction for put()/get()/remove(), as the API is different.

[ebruchez]

Also, we make use of the version: Long parameter, not present with JCache.

The keys are always strings.

Values are of types:

• XForms
  • DynamicState
  • String (same cache as above!)
  • Array[String]
• persistence
  • Option[NodeInfo]
    • converted to either
      • Permissions, sometimes using Specific, which can require caching
      • Int for version, but here we use Latest, which actually doesn't cache
      • -> in any case we need to store Permissions instead of NodeInfo
  • EncryptionAndIndexDetails

[ebruchez]

• [x] implement abstraction
• [x] implement JCache support
• [x] create Ehcache 3 configuration as example for testing
• [x] figure out a way to have Ehcache 3 load an XML configuration through Ehcache
• [x] test with Ehcache 3
• [x] handle shutdown listener in web.xml

[ebruchez]

Managed to get Ehcache 3 to work through JCache. However, I have to specify a URI pointing to the XML configuration, which of course is not cache provider-independent. Or maybe, add another property:

• if blank, use provider.getCacheManager
• if blank, use provider.getCacheManager(uri, getClass.getClassLoader)

Not sure if that makes sense.

[ebruchez]

We probably should add that URI property. However, I am not sure there is a way to specify a URI for the configuration that allows storing the configuration in a JAR or the webapp without using an absolute path, whether using file: or jar:. Still, that would allow pointing to a specific configuration. Ideally, we would use oxf:, but since we pass a URI and not a URL, and there is no independently-registered URLStreamHandler, we probably can't.

[ebruchez]

It seems that using getResource() would be a good idea. This searches under WEB-INF/lib/WEB-INF/classes and would at least allow placing a configuration file in the WAR file in an deployment-independent way.

[ebruchez]

• [x] reproduce, with ehcache2 provider, Form Builder issue (Firefox):
  • Form Builder
  • do not "Disable Cache" in dev tools
  • enter app/form names so that doc is dirty (causes unload handler and do disables bfcache)
  • open URL in URL bar to add new history entry
  • browser back
  • initial state is not found from store

[ebruchez]

• [x] document

[ebruchez]

Documented