Updated documentation

documentation/manual/working/commonGuide/configuration/WsCache.md

@@ -45,17 +45,22 @@ play.ws.cache.cacheManagerResource="ehcache-play-ws-cache.xml"
 and then adding a cache such as following into the `conf` directory:
 
 ```xml
-<ehcache
-        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-        xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd"
-        name="play-ws-cache"
-        updateCheck="false"
-        >
-
-	<cache name="play-ws-cache" maxEntriesLocalHeap="10000" eternal="false"
-		timeToIdleSeconds="360" timeToLiveSeconds="1000" overflowToDisk="false" />
-
-</ehcache>
+<config
+  xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
+  xmlns='http://www.ehcache.org/v3'
+  xsi:schemaLocation="http://www.ehcache.org/v3 http://www.ehcache.org/schema/ehcache-core.xsd">
+
+  <cache alias="play-ws-cache">
+    <key-type>java.lang.String</key-type>
+    <value-type>play.api.cache.ExpirableCacheValue</value-type>
+    <expiry>
+      <tti unit="seconds">360</tti>
+    </expiry>
+    <resources>
+      <heap unit="entries">10000</heap>
+    </resources>
+  </cache>
+</config>
 ```
 
 > **NOTE**: `play.ws.cache.cacheManagerURI` is deprecated, use `play.ws.cache.cacheManagerResource` with a path on the classpath instead.

documentation/manual/working/javaGuide/main/cache/JavaCache.md

@@ -8,7 +8,7 @@ Caching data is a typical optimization in modern applications, and so Play provi
 
 For any data stored in the cache, a regeneration strategy needs to be put in place in case the data goes missing. This philosophy is one of the fundamentals behind Play, and is different from Java EE, where the session is expected to retain values throughout its lifetime.
 
-Play provides a CacheApi implementation based on [Caffeine](https://github.com/ben-manes/caffeine/) and a legacy implementation based on [Ehcache 2.x](http://www.ehcache.org). For in-process caching Caffeine is typically the best choice. If you need distributed caching, there are third-party plugins for [memcached](https://github.com/mumoshu/play2-memcached) and [redis](https://github.com/KarelCemus/play-redis).
+Play provides a CacheApi implementation based on [Caffeine](https://github.com/ben-manes/caffeine/) and a legacy implementation based on [Ehcache 3.x](http://www.ehcache.org). For in-process caching Caffeine is typically the best choice. If you need distributed caching, there are third-party plugins for [memcached](https://github.com/mumoshu/play2-memcached) and [redis](https://github.com/KarelCemus/play-redis).
 
 ## Importing the Cache API
 

documentation/manual/working/scalaGuide/main/cache/ScalaCache.md

@@ -8,7 +8,7 @@ Caching data is a typical optimization in modern applications, and so Play provi
 
 For any data stored in the cache, a regeneration strategy needs to be put in place in case the data goes missing. This philosophy is one of the fundamentals behind Play, and is different from Java EE, where the session is expected to retain values throughout its lifetime.
 
-Play provides a CacheApi implementation based on [Caffeine](https://github.com/ben-manes/caffeine/) and a legacy implementation based on [Ehcache 2.x](http://www.ehcache.org). For in-process caching Caffeine is typically the best choice. If you need distributed caching, there are third-party plugins for [memcached](https://github.com/mumoshu/play2-memcached) and [redis](https://github.com/KarelCemus/play-redis).
+Play provides a CacheApi implementation based on [Caffeine](https://github.com/ben-manes/caffeine/) and a legacy implementation based on [Ehcache 3.x](http://www.ehcache.org). For in-process caching Caffeine is typically the best choice. If you need distributed caching, there are third-party plugins for [memcached](https://github.com/mumoshu/play2-memcached) and [redis](https://github.com/KarelCemus/play-redis).
 
 ## Importing the Cache API
 
@@ -121,7 +121,7 @@ By default, Play will try to create caches with names from `play.cache.bindCache
 ## Setting the execution context
 
 By default, Caffeine and EhCache store elements in memory. Therefore reads from and writes to the cache should be very fast, because there is hardly any blocking I/O.
-However, depending on how a cache was configured (e.g. by using [EhCache's `DiskStore`](http://www.ehcache.org/generated/2.10.4/html/ehc-all/#page/Ehcache_Documentation_Set%2Fco-store_storage_tiers.html)), there might be blocking I/O which can become too costly, because even the async implementations will block threads in the default execution context.
+However, depending on how a cache was configured (e.g. by using [EhCache's `DiskStore`](https://www.ehcache.org/documentation/3.10/tiering.html#disk-tier)), there might be blocking I/O which can become too costly, because even the async implementations will block threads in the default execution context.
 
 For such a case you can configure a different [Pekko dispatcher](https://pekko.apache.org/docs/pekko/1.0/dispatchers.html?language=scala#looking-up-a-dispatcher) and set it via `play.cache.dispatcher` so the cache plugin makes use of it: