Fix default for KIO Playbook Github Token

Fixed default for KIO Playbook GitHub Token in blueprint example deployment file.

KIO_BACKEND_PLAYBOOKS_GITHUB_TOKEN: ${KIO_GITHUB_TOKEN:-false}

If not configured, the auto config relying on this property is skipped as expected.

(CMS-28987)

Resilience4j Update

Resilience4j has been updated from version 1.7.0 to 2.3.0 for the studio-server and the content-server.

(CMS-28786)

Update of JUnit Jupiter

JUnit Jupiter has been updated to new major version 6.0.

Custom code that involves usage of changed JUnit Jupiter API may need to be adapted, see https://docs.junit.org/current/release-notes/index.html.

(CMS-28721)

Updated MySQL Driver

Updated MySQL driver to com.mysql:mysql-connector-j:9.4.0

(CMS-28559)

Configurable Cache Duration for Outdated Transformed Blobs

Added a new configuration property delivery.outdated-transformed-blob-cache-duration to control how long outdated or yet unknown transformed blobs are to be cached in a multi-CAE scenario (cae.single-node=false). Before this fix, CAE send a cache-control header with max-age of 0 seconds. This value is now configurable. Consider that a yet unknown cache should not be cached for long because the CDN should ideally cache the correct transformed blob for a given URL. The cases to cover are that (1) either a more up-to-date CAE generated the link and the CAE answering the request for the transformed blob does not yet know about the updated blob and (2) a client has stored a very old version of a transformed blob URL for which the blob data is no longer cached by the CDN. A CAE cannot distinguish between these two cases but serves the currently (either outdated or newer) known transformed blob. The new configuration property allows projects to optimize for scenario (1) or (2) by setting a (1) short duration or (2) a long duration.

Configuration example:

# Set cache duration to 1 hour
delivery.outdated-transformed-blob-cache-duration=1h

Upgrade Information

(CMS-28032)

JUnit Jupiter: Updated to 5.13.2

JUnit Jupiter has been updated to 5.13.2. Note, that this release introduces deprecations, for example, for ArgumentsProvider so that you should implement another signature of provideArguments.

For details, see the corresponding release notes: JUnit 5 Release Notes.

(CMS-28006)

Updated Hibernate to 7.1

jakarta.persistence:jakarta.persistence-api has been updated to 3.2.0

org.hibernate.orm:hibernate-core has been updated to 7.1.4.Final

hypersistence-utils have been updated to io.hypersistence:hypersistence-utils-hibernate-71:3.11.0

(CMS-27967)

Third-Party Update: commons-io 2.19.0

Apache Commons IO has been updated to 2.19.0.

(CMS-27839)

New methods Content#getLatestVersion, Content#getLatestOrWorkingVersion, Content#getCheckedInOrWorkingVersion and Content#getCheckedOutOrWorkingVersion

The com.coremedia.cap.content.Content interface has been extended with methods Content#getLatestVersion, Content#getLatestOrWorkingVersion, Content#getCheckedInOrWorkingVersion and Content#getCheckedOutOrWorkingVersion. For details see javadoc.

(CMS-27810)

Removed unused legacy CORS configuration properties

The deprecated and unused cae.cors. (CAE) and caas.cors. (Headless Server) configuration properties have been removed.

Since CMCC-12 release 2506.0.0, these delivery-specific CORS configuration properties were unused as they were replaced by the generalized cors.* configuration properties.

Please see the CORS Properties reference in the Deployment Manual.

(CMS-27692)

Third-Party Update: Checker Framework

The Checker Framework has been updated to version 3.42.0.

(CMS-27505)

Third-Party Update: Eclipse Glassfish CORBA ORB

The third-party library org.glassfish.corba has been updated to version 5.0.0

(CMS-27460)

The git-commit-id-plugin has been removed from the maven build system

The git-commit-id-plugin has been removed from the maven build. If you want to add git information to the build, it should be set on an application basis and not with a global state, otherwise every commit will change the image digest and every commit will require a redeployment of every image.

In order to get this information at runtime, we recommend to use

git log -n 1 --pretty=format:%H -- <folder>

and pass it to the jib-maven-plugin to set it as an environment variable and a label.

<configuration>
  <container>
    <environment>
      <INFO_COMMIT_ID>${git.commit.id}</INFO_COMMIT_ID>
    <environment>
    <labels>
      <INFO_COMMIT_ID>${git.commit.id}</INFO_COMMIT_ID>
    </labels>
  </container>
</configuration>

There is a caveat of this approach is that there are shared modules which might change and then would not reflect in this property. Alternatives are OCI manifest annotations which can be added after the build without changing the images digest but are not possible to access at runtime.

(CMS-27281)

jshell has been added to all java-application-base image flavors

Both the corretto-jre and the temurin-jre base image flavors now contain jshell.

(CMS-27258)

a new maven profile to build multi-arch images has been added

The new profile multi-arch complements the default-image profile and works only together with the build goal. If activated, the application.image-arch property has no effect and instead each image will be build for linux/amd64 and linux/arm64 architectures

(CMS-25935)

The cm based command-line tools have been moved to the corresponding server application images

To provide a better Kubernetes integration, the tools have been moved to the corresponding server images. For backwards compatibility, the management-tools image will still be provided.

(CMS-25844)

LdapUserProvider Connection Improvements

LDAP roundtrips ere executed with a timeout now, in order to avoid blocked threads in case of certain problems. The timeout (ldap.timeout) as well as the maximum number of connections (ldap.max-connections) is configurable now. However, the default values are supposed to be suitable for most projects, and there should be no need to change them unless concrete problems occur. There is another new configuration property ldap.referral-throw-handling to control the details of referral handling. It is still experimental, because the details concerning referrals depend on the particular setup of the LDAP servers, and this has not yet been tested exhaustively. But if you encounter problems with the default behaviour, you should give it a try.

See com.coremedia.ldap.LdapUserProviderConfigurationProperties for details.

(CMS-23359)

Running with 2 retries at fixed delays of 1 and 5 seconds

(CMS-22581)