Fixed Cache Capacity Handling and Reporting of DataViewFactory

The DataViewFactory did not respect the configured cache capacities and fell back to the capacity of "java.lang.Object" for cache capacities whose keys did not represent the names of classes extending com.coremedia.objectserver.dataviews.AssumesIdentity or com.coremedia.objectserver.dataviews.DataView. This is the case for com.coremedia.blueprint.common.contentbeans.Page, for example. The DataViewFactory no longer maintains its own mapping of cache capacities but uses the capacities which are configured at the Cache bean. The DataViewFactory records the used cache classes and reports the corresponding cache capacities via JMX using the CacheSizes attribute or the getCacheSizes operation.

The cache size definitions from dataviews XML files have lower precedence than those defined at the cache. So if your project contains a cachesize entry for class X with value Y and your application config contains an entry cache.capacities.X=Z then the cache capacity is Z.

(CMS-20774)

Solved a Bug Preventing CAE Background Tasks to Access Contents Filtered by Validity Dates

Bean BlueprintHandlersCaeBaseLibConfiguration#validUntilConsumer no longer throws an exception if the current request is not available when consuming a validity change instant.

(CMS-19458)

Prevent Errors when Formatting Links from Download File Names

The `CapBlobHandler` now returns a UriComponentsBuilder object instead of a String when when building download links. This prevents error-prone guessing if provided links are URL encoded or not in the link formatter. Such errors could occur when useCMDownloadFilename=true and the file name of a download contains both, encoded and unencoded characters (e.g. a + and a space).

(CMS-19259)