Patch Level Update

Downsized WildFly distribution

Starting with Camunda 7.24.2, 7.23.7, and 7.22.10 the WildFly distribution has been optimized to reduce its size by approximately 30%. This is achieved by using Galleon provisioning with only the layers strictly required for Camunda 7 operation.

Benefits of Optimized Distribution

• Smaller footprint: Reduced disk space and memory usage by ~30%
• Faster startup: Fewer subsystems to initialize
• Improved security: Reduced attack surface by removing unused components
• Better containerization: Smaller Docker images

Minimal Required Galleon Layers

The following Galleon layers are sufficient to run Camunda 7 on WildFly:

• core-tools
• core-server
• datasources
• cdi
• deployment-scanner
• servlet
• jaxrs-core
• ejb
• jpa

Depending on your deployment scenario, there might be even fewer needed Galleon layers. For example, if you don’t use EJBs, you can omit the ejb layer. However, the above list covers the most common use cases.

Distribution Changes

The optimized distribution uses Galleon provisioning instead of a full WildFly installation. This means:

• Unnecessary WildFly components (appclient, domain mode scripts, web services tools, etc.) are removed
• Only the essential modules required for Camunda 7 are included

Module Descriptor Updates

As part of the optimization, deprecated module dependencies have been removed from module.xml descriptors. These dependencies are no longer needed and were causing exceptions in recent WildFly versions.

Removed Dependencies

The following dependencies have been removed from Camunda module descriptors:

• sun.jdk - This module is obsolete in modern JDK versions
• javax.api - Replaced by Jakarta EE APIs

Affected Modules

The following module descriptors have been updated to remove deprecated dependencies:

• org/camunda/bpm/camunda-engine/main/module.xml
• org/camunda/bpm/identity/camunda-identity-ldap/main/module.xml
• org/camunda/bpm/wildfly/camunda-wildfly-subsystem/main/module.xml
• org/camunda/bpm/dmn/camunda-engine-feel-scala/main/module.xml
• org/camunda/feel/feel-engine/main/module.xml
• org/apache/groovy/groovy-all/main/module.xml
• com/ibm/icu/icu4j/main/module.xml
• org/graalvm/js/js/main/module.xml
• org/graalvm/js/js-scriptengine/main/module.xml
• org/graalvm/regex/regex/main/module.xml
• org/graalvm/sdk/graal-sdk/main/module.xml
• org/graalvm/truffle/truffle-api/main/module.xml

Example Change

Before:

<module xmlns="urn:jboss:module:1.9" name="org.camunda.bpm.camunda-engine">
    <dependencies>
        <module name="sun.jdk"/>
        <module name="javax.api"/>
        <module name="org.camunda.commons.camunda-commons-logging"/>
        <!-- other dependencies -->
    </dependencies>
</module>

After:

<module xmlns="urn:jboss:module:1.9" name="org.camunda.bpm.camunda-engine">
    <dependencies>
        <module name="org.camunda.commons.camunda-commons-logging"/>
        <!-- other dependencies -->
    </dependencies>
</module>

Migration from Full WildFly Distribution

If you are updating from an earlier version that used a full WildFly installation, note the following differences.

Removed Components

The following WildFly components are no longer included in the optimized distribution:

• Application Client: appclient/ directory and related scripts
• Domain Mode: Domain configuration files and scripts
• Web Services Development Tools: wsconsume and wsprovide utilities
• Additional Subsystems: Various EE subsystems not required by Camunda 7 (see Removed Modules below)

Removed Modules

The optimized distribution removes numerous WildFly system layer modules that are not required for Camunda 7, including:

• Application client modules
• Web services client tools
• Domain management modules
• Advanced clustering and messaging features
• MicroProfile extensions (beyond core requirements)
• Legacy compatibility modules (javax.api, sun.jdk)

For a complete list of removed modules, compare the modules/system/layers/base/ directory between the old and new distributions.

Configuration Files

The following standalone configuration files are no longer included:

• standalone-full-ha.xml
• standalone-full.xml
• standalone-ha.xml
• standalone-load-balancer.xml
• standalone-microprofile-ha.xml
• standalone-microprofile.xml

Only standalone.xml is included, which is sufficient for most Camunda 7 deployments.

Creating Custom Galleon Provisioning

If you need additional WildFly features beyond the minimal set, you can create a custom Galleon provisioning configuration:

1. Install the Galleon CLI tool

2. Create a provisioning configuration file (e.g., provision.xml):

   <?xml version="1.0" ?>
   <installation xmlns="urn:jboss:galleon:provisioning:3.0">
   <feature-pack location="org.wildfly:wildfly-galleon-pack:37.0.0.Final">
       <default-configs inherit="false"/>
       <packages inherit="false"/>
   </feature-pack>
   <config model="standalone" name="standalone.xml">
       <layers>
           <!-- Minimal Camunda 7 layers -->
           <include name="core-tools"/>
           <include name="core-server"/>
           <include name="datasources"/>
           <include name="cdi"/>
           <include name="deployment-scanner"/>
           <include name="servlet"/>
           <include name="jaxrs-core"/>
           <include name="ejb"/>
           <include name="jpa"/>
               
           <!-- Add additional layers as needed -->
           <!-- <include name="your-additional-layer"/> -->
       </layers>
   </config>
   </installation>
   

3. Provision WildFly with Galleon:

   galleon.sh provision /path/to/provision.xml --dir=$WILDFLY_HOME
   

4. Copy Camunda modules and configuration from the Camunda WildFly distribution

Additional Resources

• WildFly Manual Installation Guide
• WildFly Configuration Guide
• WildFly Galleon Documentation
• WildFly Galleon Layers

Camunda Run: Spring Boot 3.5 Upgrade

Camunda Run is now based on Spring Boot 3.5, upgrading from Spring Boot 3.3 which has reached end-of-life.

Migration Steps

For standard Camunda Run usage, no action is required beyond upgrading to version 7.21.13.

For custom Spring Boot configurations:

1. Review Custom Configuration: If you have applied custom Spring Boot-specific configuration to your application.yml or application.properties, ensure compatibility with Spring Boot 3.5
2. Update Dependencies: If you have added custom Spring Boot dependencies, verify they are compatible with Spring Boot 3.5
3. Test Your Setup: Verify that your Camunda Run instance starts and functions correctly after the upgrade

Expected Impact

We expect no migration to be needed for most users, as this upgrade primarily addresses security updates and dependency maintenance. The Spring Boot configuration interface remains largely compatible between versions 3.3 and 3.5.

For detailed information about Spring Boot 3.5 changes, refer to the release notes:

• Spring Boot 3.4 Release Notes.
• Spring Boot 3.5 Release Notes.

Docker Base Image Update

The Docker base image has been updated from Alpine Linux 3.18 to Alpine Linux 3.22.

Migration Steps

For standard Docker image usage, no action is required beyond pulling the 7.21.12 / 7.22.7 / 7.23.4 image.

For custom Docker configurations:

1. Assess Custom Code: Review any Alpine-specific customizations for version 3.22 compatibility
2. Update Dependencies: Check that the additional packages you install are available in Alpine 3.22
3. Rebuild Custom Images: Update Dockerfiles that extend the Camunda base image
4. Test Migration: Verify functionality after updating to the new base image

For detailed information about changes across Alpine versions, refer to the following release notes:

• Alpine Linux 3.19 Release Notes
• Alpine Linux 3.20 Release Notes
• Alpine Linux 3.21 Release Notes
• Alpine Linux 3.22 Release Notes

See the Alpine Linux documentation for comprehensive change details.

GraalVM Upgrade

We are pleased to announce that the above patch releases are compatible with GraalVM 21.3.12

The engine will automatically disable the system property polyglot.engine.WarnInterpreterOnly when a GraalJS script engine is used.

This adjustment ensures a smoother experience by suppressing unnecessary warnings related to interpreter-only execution in non-native GraalVM environments which might cause confusion to our users running on non-GraalVM JDKs.

You can read more about the warnings here.

The 7.22.0 release replaced the runtime with the historic process instance query in Cockpit when performing a Process Instance Batch Modification.

The 7.22.0 release introduced a limitation for the Activity ID filter: Filtering for activities marked as asyncBefore/asyncAfter with active instances didn’t yield process instances when using the Activity ID filter.

After some user feedback, we understood that there are use cases that cannot be catered with this limitation in place leading to undesired behavior. With this patch release, we lifted this limitation by opting for a different solution approach which restored the previous behavior.

Set Variables Async API

Before version 7.22.1, the Set Variables Async API failed whenever at least one of the process instances did not exist.

Starting with version 7.22.1, the behavior has changed: if any of the process instances was deleted or completed, the call will still succeed. As a consequence, the Set Variables Batch Operation will also succeed in this case.

Please note that this does not apply to the Sync API, which keeps its behavior and fails if the process instance does not exist.

Bootstrap NES and AngularJS NES by HeroDevs, Inc.

These patches replace the following libraries with versions of Bootstrap NES and AngularJS NES by HeroDevs, Inc.:

• AngularJS (technical names: angular, angular-animate, angular-cookies, angular-loader, angular-mocks, angular-resource, angular-route, angular-sanitize, angular-touch)
• angular-ui-bootstrap
• angular-translate
• angular-moment
• Bootstrap

Where AngularJS, angular-ui-bootstrap, angular-translate, angular-moment, and Bootstrap were licensed entirely under the MIT license, Bootstrap NES and AngularJS NES by HeroDevs, Inc. licenses additional parts under the HeroDevs NES License. By downloading and using Camunda with Bootstrap NES and AngularJS NES by HeroDevs, Inc., you agree to the terms of the HeroDevs NES License. You can find the HeroDevs NES License terms in our License Book.

Please see our third-party libraries documentation for details.

Added Support for Tomcat 10

This version supports all the necessary building-block modules for our users to use camunda-bpm-platform community and enterprise editions in conjunction with Tomcat 10.1.

Changed trigger order of built-in task listeners

Built-in task listeners are used internally by the engine and not intended to be used by the user. User-defined task listeners are handled separately. Before this release, the order in which builtin task listeners were executed could depend on how the task was executed. This bug report describes a scenario where after a process instance modification, the order of the builtin task listeners was reversed. With this release for both, regular process execution and process instance modification, the engine ensures the following:

1. Built-in task listeners are executed before user-defined task listeners.
2. Built-in task listeners are executed in the order in which they were registered.
3. User-defined task listeners are executed in the order in which they were registered.

Previously, only 1. and 3. were ensured.

Cockpit’s process definition like search changed to case-insensitive

The Cockpit/Processes’s page Process Definition search component allows for name and key search with equals and like operators. With this recent change, per customer feedback, we modified the like search to case-insensitive. This will allow a better experience when looking for process definitions.

The change also affects the API that provides the data for the search component. This API is an internal API, which means it’s not part of the public REST API, so the change should not affect any customers.

Spring Boot Starter and Run logs admin user information on DEBUG level

In previous releases, when configuring Camunda’s admin user in the Spring Boot Starter and Run via camunda.bpm.admin-user, information about the admin user appeared in the logs on log level INFO on startup. With this release, the log level for the logs STARTER-SB010 and STARTER-SB011 was changed to DEBUG.

Update Alpine Base of Camunda Docker images from Version 3.15 to 3.18

The Camunda Docker images are based on Alpine. This release updates the Alpine base docker image from version 3.15 to 3.18. Please find the changes in detail at the official sources below:

• Alpine 3.16.0 Release Notes
• Alpine 3.17.0 Release Notes
• Alpine 3.18.0 Release Notes

Explicit asset declaration in Java web app plugins

We introduced a change in the asset loading mechanism for Java web app plugins. Starting with this release, plugin assets must be explicitly declared in the plugin root resource class. You can declare your assets by overriding the AbstractAppPluginRootResource#getAllowedAssets() method in your root resource.

The default implementation contains two predefined assets: app/plugin.js and app/plugin.css. For many plugins this might be already sufficient and will require no further assets to be allowed.

Custom scripts and frontend modules are not affected by this.

Bean method resolution from JUEL expressions

Calling bean methods from JUEL expressions now works more reliably and supports overloaded methods. As a result, the behavior of calling overloaded methods from such expressions changes.

Previoulsy, overloaded methods couldn’t be determined reliably and were chosen based on the order of the underlying JDK’s result of the call to Class#getMethods for a specific method name. As a result, the expected method might have been chosen for the expression evaluation but this could not be guaranteed.

Now, the most specific version according to the provided number and types of method parameters is chosen consistently. For example, method myMethod expecting an Integer is chosen over method myMethod expecting an Object if the provided parameter is an Integer or can be coerced into one.

Ideally, you shouldn’t notice any difference in method invocation from JUEL expressions. However, we recommend testing your existing expressions thoroughly before using this patch version in production.

Optimistic Locking on PostgreSQL

With this release, we adjusted the Optimistic Locking behavior on PostgreSQL in case of Foreign Key Constraint violations. Any violation of such a constraint in INSERT and UPDATE statements now leads to an OptimisticLockingException. In effect, the engine’s behavior on PostgreSQL in such scenarios is consistent with the other supported databases.

If you rely on the previous behavior, receiving ProcessEngineExceptions with the related error code for foreign key constraint violations, you can restore it by disabling the engine configuration flag enableOptimisticLockingOnForeignKeyViolation. As a result, jobs can also start failing due to those exceptions although they could be safely retried automatically to resolve the situation.

Web apps revalidate authentications every five minutes

Previously, after a user logged into the web apps, the authentication cache was valid for the lifetime of the HTTP session, which has security implications.

With this release, we introduced a time to live for the authentication cache, configured to five minutes by default. This new default might lead to a higher load on your database.

You can read how to configure the time to live to a smaller interval or restore the legacy behavior (disable the authentication cache time to live) in the documentation about Web Applications.

Container-based authentication requires implementing a ReadOnlyIdentityProvider

When using Container-based Authentication, please provide an implementation for the ReadOnlyIdentityProvider interface so that queries return the results of your identity provider.

This is necessary due to the aforementioned security improvement to revalidate users and groups.

Multi-Tenancy enabled for User operation logs

Tenant information is populated for User operation logs from 7.18.5 onwards, user operation logs created prior will stay as they are. If tenant check is enabled in the process engine, a tenant membership check will be performed for the following operations:

• User operation log query
• Deleting a user operation log
• Adding/Clearing a user operation log annotation

In case you want to avoid tenant checks, please refer to Disable the transparent access restrictions.

Job executor priority range properties default changed

The default value for the job executor priority range property jobExecutorPriorityRangeMin has changed from 0 to -263 (Long.MIN_VALUE). This property and its counterpart (jobExecutorPriorityRangeMax) only have an effect if jobExecutorAcquireByPriority is set to true.

Job executor priority range properties type changed

The two dedicated job executor priority range properties jobExecutorPriorityRangeMin and jobExecutorPriorityRangeMax have been change to primitive type long. That allows for the properties to be configured for every process engine configuration. Respectively their default values changed to 0 and 263-1 (Long.MAX_VALUE). Note: this behavior is slightly changed with the next patch.