Release Notes / Version 12.2506.0
Table Of ContentsDynamic Cache Class Configuration of Cache Keys
If no specific cache class is defined via
CacheKey#cacheClass(Cache, T), lookup of a cache
class for the cache key is now done by traversing the type hierarchy
against the configured capacities of a cache. See Java documentation
for
com.coremedia.cache.CacheKey#cacheClass(Cache, T)
and
com.coremedia.cache.Cache#cacheClassFor(Class<?>).
This mechanism can be employed if cache keys predefined by the product
or defined in your project shall be pulled from default cache class
java.lang.Object into a dedicated cache class. This
way, cache optimization can be performed without changing cache class
definition in the code of CacheKey implementations.
Upgrade Information
A cache key may be put into a dedicated cache class by configuring a
cache capacity for its class (see Java documentation for
com.coremedia.cache.CacheKey#cacheClass(Cache, T)
and
com.coremedia.cache.Cache#cacheClassFor(Class<?>)).
Example: if a dedicated cache class shall be defined for cache key
com.coremedia.blueprint.cae.view.resolver.ThemeTemplateViewRepositoryProvider$TemplateLocationsCacheKey,
add the following line (with appropriate capacity for your project) to
the Spring configuration of your CAEs:
cache.capacities.com.coremedia.blueprint.cae.view.resolver.ThemeTemplateViewRepositoryProvider.TemplateLocationsCacheKey=100
However, it is not strictly necessary to move cache keys from default
cache class java.lang.Object into a dedicated cache
class unless
a high eviction rate is observed and the cache capacity cannot be increased or
the cache requires too much Java heap occasionally and the heap cannot be enlarged.
In those cases, introducing dedicated cache classes will give you better control over eviction rate and heap consumption.
Use actuator endpoint
http://<host>:<management-port>/actuator/cache/java.lang.Object?keys=true
to get information about cache keys that are currently stored in the
default cache class.
(CMS-30042)
Third-Party Update: Apache Tika 3.3.0 and Transitive Dependencies
Apache Tika has been updated to version 3.3.0. As part of this change, transitive dependencies of Apache Tika have been updated.
Updated dependencies:
Apache PDFBox 3.0.7
Apache POI 5.5.1
Apache Tika 3.3.0
ASM 9.9.1
Glassfish JAXB 4.0.7
Jakarta Activation API 2.1.4
Jakarta Bind API 4.0.5
JHighlight 1.1.1
jsoup 1.21.1
picocli 4.7.7
XZ for Java 1.12
With this update, Tika dependencies switched from using transitive
dependency org.apache.poi:poi-ooxml-lite to
org.apache.poi:poi-ooxml-full (TIKA-4563). If you
use the former in your own code for Studio
Server, Content Feeder or
CAE Feeder, consider switching to the latter to
avoid duplicate classes from different JAR artifacts
If you use these libraries in project code, please check their respective release notes for changes and upgrade information.
(CMS-29980)
Third-Party Update: Apache Zookeeper
Apache Zookeeper has been updated to version 3.9.5.
(CMS-29840)
Document Check-in on Server Import Handles Already Checked-in Documents Gracefully
When finishing content import by tool serverimport,
all imported documents are checked in. Previously, this step failed if
recently imported documents were checked in by other processes (user
interaction in Studio or other tool) which led to errors in tool's
response and left subsequent check-ins unfinished. This is now
changed, so that already checked-in documents no longer provoke an
error.
(CMS-27210)


