About release 2.2
New and Noteworthy
New Web Applications (webapps-neo) — Technical Preview
Operaton 2.2 integrates a new, Preact-based implementation of the web applications
(webapps-neo) into the main repository as a technical preview alongside the existing legacy
web applications. It reuses the same backend Java logic as the legacy webapps and ships a first
administrator setup screen for initial deployment.
The initial integration was followed up with fixes to make the packaged distribution usable and
to close security defects found while reviewing it against a real build: the SPA's own bundle
was being blocked by the Content-Security-Policy, login for the new app id was rejected, CSP
nonces were not scoped per request, error responses were missing security headers, and an
authorization rule that should have denied /api/admin/** did not.
This implements PR #3296 and PR #3515.
SKIP LOCKED Job Acquisition
This is a preview feature we publish to gather real feedback. There is no guarantee that the config properties, API or behavior won't change until the final release.
The job executor can now acquire jobs using FOR UPDATE SKIP LOCKED, so that parallel nodes
skip rows another node has already locked instead of blocking on them. In clustered setups this
removes the contention that previously showed up as rejected job executions when many nodes
polled the same set of due jobs. This is not an automatic performance improvement, as the feature
puts more load on the database itself, so its value depends on database sizing, database type and
the quality of the network connection between Operaton and the database.
Activate it through ProcessEngineConfiguration#setJobExecutorAcquireWithSkipLocked(true), or
in Spring Boot:
operaton:
bpm:
job-executor-acquire-with-skip-locked: true
Existing installations keep the previous acquisition behaviour until the property is set.
Two details are worth knowing before switching it on:
- Exclusive jobs keep their previous semantics. With SKIP LOCKED active, exclusive and non-exclusive jobs are acquired in separate queries. Exclusive jobs are deliberately acquired without SKIP LOCKED, because their contention-based serialization is what guarantees that jobs of the same process instance are not executed in parallel. Expect the throughput gain on non-exclusive jobs.
- The statement is database-specific. Where the standard syntax does not apply, Operaton ships a dedicated query: Oracle tolerates neither a subquery wrapper nor a row limit alongside FOR UPDATE SKIP LOCKED, DB2 uses FOR UPDATE WITH RS USE AND KEEP UPDATE LOCKS SKIP LOCKED DATA, and SQL Server uses the UPDLOCK/READPAST hints instead. PostgreSQL, MySQL, MariaDB and H2 use the standard form.
This implements issue #264 (https://github.com/operaton/operaton/issues/264) via PR #326 (https://github.com/operaton/operaton/pull/326).
Spring Boot 4.1 Upgrade
Operaton 2.2 upgrades the Spring Boot baseline from 4.0.x to Spring Boot 4.1. This upgrade brings in the latest Spring Framework improvements, updated dependency baselines, and continued alignment with the Spring ecosystem's active release line.
Existing Spring Boot applications built on Operaton 2.1 should migrate smoothly. Refer to the Spring Boot 4.1 migration guide for any application-level adjustments.
This implements PR #2844.
WildFly 41 Upgrade & CDI 4.1 Compatibility
Operaton 2.2 upgrades the WildFly distribution to WildFly 41 and adapts the CDI integration to the Jakarta CDI 4.1 standard API.
Key improvements:
-
BeanManagerlookup via CDI 4.1 standard API: TheBeanManageris now resolved through the Jakarta CDI 4.1 standard API (CDI.current().getBeanManager()), which works correctly inside the WildFly module classloader. The previous approach relying on JNDI lookup could fail in certain module isolation scenarios. -
Null-safe
CdiResolver:CdiResolveris now null-safe to prevent breaking the EL resolver chain when CDI is not fully initialised or unavailable in a given context. -
Optional module dependencies: The module descriptor now declares
jakarta.faces.apiandjakarta.enterprise.concurrent.apias optional module dependencies, so process application WARs that do not use JSF or Concurrent Utilities are not forced to depend on those modules. -
No
jboss-deployment-structure.xmlrequired: As a direct consequence of the CDI lookup and optional-dependency changes, process application WARs no longer need ajboss-deployment-structure.xmlto control module visibility. Standard WAR packaging works out of the box on WildFly 39+.
This implements PR #2781, PR #3153.
Nullability Declarations in the Engine API
Operaton 2.2 begins annotating engine internals with JSpecify
@Nullable/@NullMarked annotations, making the nullability contract of engine APIs explicit and
tool-checkable (e.g. via IDE inspections or static analysis) instead of relying purely on
Javadoc or convention.
This is an incremental, non-breaking effort — annotations are being added class by class, package by package, starting with engine internals and going through to the public API. For background on the approach and rollout plan, see the forum announcement "Introducing declaration of nullability in the API" and the underlying ADR "Null Safety Strategy for Operaton".
This implements PR #3590, PR #3618, PR #3634, PR #3642, PR #3658, PR #3666.
Root Process Instance ID Added to MDC
The root process instance ID is now included in the MDC (Mapped Diagnostic Context) under
the key rootProcessInstanceId. This makes it straightforward to correlate log output across
call hierarchies that span multiple sub-process instances or called processes back to the
top-level root instance, improving distributed tracing and log aggregation.
This implements PR #3114.
Deadlock Detection for GraalJS Script Tasks
Operaton 2.2 improves the robustness of the DbSqlSession concurrency handling by detecting
deadlock conditions more reliably. The fix specifically addresses a scenario where GraalJS script
task execution could trigger a deadlock that was previously not recognized as a concurrent
modification exception, preventing proper retry handling.
Task Authorization Query Performance
Task list and task count queries that use authorization checks now use an EXISTS subquery
instead of joining ACT_RU_AUTHORIZATION into the main result set.
Under high load or with large authorization tables, the previous join approach could inflate the
intermediate result set, causing slow task queries. The new EXISTS path short-circuits the
authorization check as soon as a matching row is found.
This resolves PR #3152.
MDC Logging: Process Definition Key from Stored Execution Property
When the MDC logging context requires the process definition key, the engine now reads it from
the already stored ExecutionEntity#getProcessDefinitionKey() property instead of resolving the
full process definition via a database lookup, avoiding unnecessary database round-trips during
logging.
This resolves PR #3109.
Date Form Values Accepted Correctly
A bug in the deprecated DateFormType.convertFormValueToModelValue(Object) path caused an error
when a date entered in one task was reused as the default value of another task's form field: the
converter received an already-converted Date object instead of a String, and rejected it.
The converter now accepts Date values directly in addition to String values.
This resolves PR #3089.
Attachment Delete Null Pointer Exception Fixed
A NullPointerException that could occur when deleting a task attachment without an associated
content byte array has been fixed.
This resolves PR #3088.
FEEL Engine Switched to the Unshaded Artifact
Operaton 2.2 replaces the shaded feel-engine classifier from org.camunda.feel with the
plain, unshaded artifact, and manages its real dependency tree (Scala, fastparse, geny,
sourcecode, jackson-module-scala) explicitly instead.
The shaded jar relocated Scala and fastparse to camundajar.impl.*, but bundled Jackson and
paranamer without relocation. This caused duplicate-class conflicts with applications' own
Jackson dependency (flagged by Maven Enforcer's banDuplicateClasses), and classpath-order
dependent version mixing when the bundled Jackson classes clashed with a differing
jackson-annotations version on the classpath. With the unshaded artifact, FEEL deterministically
uses the platform's Jackson, governed by the shared jackson-bom import.
Applications embedding the engine no longer need to work around these conflicts; the WildFly and Tomcat distributions now ship proper modules/libraries for the additional third-party jars this change pulls in.
This implements PR #3342.
Security: Pinned Vulnerable Transitive Netty and Jackson Versions
Operaton 2.2 pins netty-bom to 4.2.16.Final and adds a jackson-bom (Jackson 3,
tools.jackson) import at 3.1.5, overriding the vulnerable transitive versions still
managed by the current Quarkus (Netty 4.2.15, affected by CVE-2026-56745 and related
advisories) and Spring Boot (Jackson 3 3.1.4, affected by CVE-2026-59889) dependency
platforms. Both pins are temporary and documented as removable once the respective upstream
BOMs ship a fixed version.
This resolves PR #3390.
Quarkus Updated to 3.33.3.1
The Quarkus platform dependency has been updated to 3.33.3.1, the latest patch release on the 3.33 LTS line.
This implements PR #3386, PR #3507.
Docker Images for Java 17, 21 and 25
The Operaton Docker images can now be built for
a specific Java version. A new build argument JAVA_VERSION (17, 21 or 25) selects the
JDK. The default is 17, so existing tags keep their content.
Images for Java 21 and 25 carry a -jdk21 or -jdk25 tag suffix. Java 17 images are
additionally tagged with -jdk17, which is identical to the tag without suffix:
| Tag | Java |
|---|---|
<version> | 17 |
<version>-jdk17 | 17 |
<version>-jdk21 | 21 |
<version>-jdk25 | 25 |
The suffix applies to snapshot tags as well, for example SNAPSHOT-jdk25 or
2.1.6-SNAPSHOT-jdk21. The CI workflows now build and test all three Java versions.
To build an image yourself:
docker build --build-arg DISTRO=run --build-arg JAVA_VERSION=21 -t operaton/operaton:jdk21 .
This implements PR #42 in the
operaton-docker repository.
API
Database Schema
Operaton 2.2 does not introduce changes to the database schema.
REST API
No REST API contract changes in this milestone release.
New APIs
No new public APIs in this milestone release.
Removed & Changed APIs
No removed or changed public APIs in this milestone release.
Usage of deprecated APIs
It is strongly recommended to avoid using deprecated methods which are marked with the @Deprecated(forRemoval = true)
annotation in the Java API.
Deprecated methods within packages containing the segment .impl. are considered internal and should not be used by clients.
These methods are subject to removal without prior notice.
Versions & Compatibility
Java
Operaton requires Java 17 as the minimum version.
Operaton is tested and supported on Java 17, Java 21, and Java 25.
Camunda 7 Compatibility
This release is feature complete and API-compatible with Camunda 7 CE 7.24.
Spring
Operaton is based on:
- Spring Boot 4.1.0
- Spring Framework 7.0.7
Quarkus Extension
The Operaton Quarkus extension is based on Quarkus 3.33.3.1 LTS.
Distributions
The Tomcat distribution is based on Tomcat 11.0.26.
The WildFly distribution is based on WildFly 41.0.0.Final.
Database Compatibility
| Database | Minimum version | Notes |
|---|---|---|
| PostgreSQL | 14 | PostgreSQL 13 EOL November 2025 |
| MariaDB | 10.11 | 10.11 is the current LTS branch |
| MySQL | 8.4 | 8.4 is the current LTS branch |
Oracle (21), SQL Server 2022, and DB2 support is unchanged.
Standards Compliance
Operaton is compliant with the following standards:
- Jakarta EE 11
- BPMN 2.0
- DMN 1.3
- CMMN 1.1
Scripting Languages
Operaton supports the following scripting languages:
| Language | Engine | Version |
|---|---|---|
| JavaScript | GraalVM JavaScript | 25.0.3 |
| Groovy | Groovy | 5.1.2 |
| Python | Jython | 2.7.4 |
| Ruby | GraalVM Ruby | 9.1.17.0 |
Dependency Upgrades
The following non-test dependencies have been upgraded since Operaton 2.1:
| Dependency | 2.1 | 2.2 |
|---|---|---|
| Spring Boot | 4.0.6 | 4.1.0 |
| Apache Tomcat | 11.0.21 | 11.0.25 |
| WildFly | 38.0.1.Final | 41.0.0.Final |
| Jackson | 2.21.2 | 2.21.4 |
| Groovy | 5.0.5 | 5.1.0 |
| Quarkus | 3.33.1 (LTS) | 3.33.3.1 (LTS) |