close

Filter

loading table of contents...

Release Notes / Version 12.2506.0

Table Of Contents

CoreMedia Core

Dynamic 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)

Search Results

Table Of Contents
warning

Your Internet Explorer is no longer supported.

Please use Mozilla Firefox, Google Chrome, or Microsoft Edge.