← All release notes

Chenile 2.1.29–2.1.34 Release Notes

This note brings together the user-facing changes across the Chenile release train from 2.1.29 through 2.1.34. It focuses on runtime behavior, new extension points, generated projects, and upgrade considerations; routine dependency alignment and maintenance-only commits are omitted.

The repositories share a coordinated version under chenile-parent. Upgrade the parent and the Chenile artifacts used by an application as one release train. Version 2.1.32 was committed as a version bump but was not tagged as a standalone release. Its runtime work is therefore described with the related process-management and generator changes that followed it.

Release highlights

2.1.29: numeric JPA identifiers

JPA applications can choose framework base classes for database-generated Long or Integer identifiers, or use typed application-generated identifier extension points. This is opt-in: existing ChenileEntity String identifiers, ID generators, and STM persistence retain their behavior. Changing the key type of an existing table remains an application-owned data migration.

See the numeric JPA identifier guide and the 2.1.29 release notes.

2.1.30: query, workflow, worker, and Azure messaging extensions

The optional JDBC Query Catalog loads reviewed MyBatis mapper XML and query definitions from a dedicated read-only datasource at startup. Packaged query files remain the default. When enabled, catalog validation failures stop startup so invalid definitions do not silently enter service.

Workflow persistence can select an EntityStore by tenant, context, or an application strategy, then fall back to the original store. Existing workflows need no override configuration.

Process worker payload and invocation failures now reach the process daemon as errors instead of being logged while work appears successful. Unknown JSON properties are tolerated for additive payload evolution; incompatible known fields still fail visibly.

Azure Event Hubs publishers can select a physical partition, a partition key, or automatic distribution per message. Logical-topic handlers provide a transport-neutral consumer path while retaining the existing EventProcessor fallback. Existing publisher behavior continues to use partition 0 unless a routing mode is selected.

The full enablement and migration guidance is in the 2.1.30 release notes.

2.1.31: service contracts and process management

Services without an HTTP dependency

@ChenileController and the shared annotation initialization lifecycle moved into chenile-core. A Spring bean can expose Chenile operations without being an HTTP controller; an HTTP endpoint still uses Spring’s @RestController and the HTTP adapter. Headless services declare operations with @ChenileOperation and identify body parameters with @ChenileBody.

The MVC mapping implementation was consolidated. Existing composed mappings such as @GetMapping and @PostMapping remain supported, and invalid ambiguous verb/route metadata fails at startup. Later in this release range, support for multiple URLs on an operation was restored with backward-compatible operation metadata. Chenile services can also return response headers through the HTTP adapters, allowing services to provide headers such as Location without controller-specific handling.

JSON ingress uses the shared Chenile transformation path after decoding, including context-based substitutions. Payload conversion stays in the framework rather than requiring each transport-specific service to parse or mutate request bodies.

Service-registry controls and diagnostics

An individual controller can opt out of service-registry publication while remaining locally available. A read-only registry mode lets an application consume and cache registry metadata without publishing local services or allowing delegate writes. These controls are additive; publication remains on by default.

Target invocation diagnostics now retain the operation, exception type, and underlying message. REST Cucumber helpers gained reusable assertions for collections and arbitrary item key/value pairs.

JGen added chenile-headless-service for non-HTTP Chenile services and a chenile-ecosystem blueprint that composes HTTP services, mini-monoliths, optional registry hosts, cconfig, headless services, and query services. Blueprints can declare sinceVersion; JGen validates compatibility before running hooks or generating files. Mini-monolith generation can also include cconfig as an application-selected dependency.

Process definitions, events, and durable commands

Process definitions can be loaded from a database through DatabaseProcessConfigurator; classpath JSON remains the default. Splitters, executors, and aggregators share the ProcessDef.config contract. Successor processes are configured by predecessor type and can select predecessor input, output, or both. The obsolete dormant/activate lifecycle was removed: leaf processes start execution directly, while composite processes begin by splitting.

The process system gained trigger ingress, persistent cron schedules, process-lineage tracking, completion events, and an administration API with a React dashboard. An optional transactional outbox introduced framework-managed commands for subprocess creation, parent signaling, worker handoff, and completion events. The command lifecycle separates enqueueing from dispatch, with retries and dead-letter visibility. A standalone administration server and a JGen process-management blueprint made the runtime easier to run and generate.

Completion notifications are emitted as ProcessCompletedEvent and delivered through Chenile event processing to ProcessManager, after the process transition transaction closes. Trigger input carries its source and JSON trigger context; x--prefixed headers can travel as context fields across JVM boundaries. Trigger and event services pass payloads through the normal Chenile transformation path instead of parsing them themselves.

The later 2.1.32–2.1.34 work refined those contracts: process effects run at a durable transaction boundary, trigger acknowledgement and once-only execution use the shared outbox ID, and the separate completion-event persistence table was removed. A trigger call returns its outbox ID as an acknowledgement; it does not return the later process output. That ID is also the trigger ID stored on a process created by the trigger. The outbox provides the once-only execution record, so a separate submission wrapper and independent trigger execution table are unnecessary. Non-durable process execution was retired so transition effects follow the durable delivery path. Applications using process persistence should review their actual deployed schema and process definitions against the release-specific process-management guides before upgrading.

See the 2.1.31 release notes, process management, trigger framework, and durable outbox guides.

2.1.32–2.1.33: deployment blueprints and modular contracts

The process deployment model now separates a server mini-monolith from a headless worker mini-monolith. The server hosts process management, crontab, trigger ingress, and optionally the service registry. Workers package the process delegate and generated business workers, then reach the server through the registry-backed delegate. The process-management blueprint owns the queue topic and listener configuration: the configured topic and Chenile event ID are both process-work, and the generated headless listener uses that same topic. One listener can serve multiple worker modules. Kafka integration tests use Testcontainers rather than a separately managed broker.

Process definitions are exposed through a Chenile REST API. Crontab was split into crontab-api and crontab-service, with its own controller, so consumers can depend on contracts without depending on implementation modules. Shared outbox and process-delegate artifacts were consolidated and the retired process-utils dependency was removed.

JGen blueprints became composable. They can accept a SuperPOM and named POM_Dependencies inputs, expand nested blueprint folders with string parameters, repeat blueprint expansion over collections, and skip nested expansion under a false conditional folder. Declarative validation rules let blueprints request checks for identifiers, types, packages, project names, versions, URLs, and Kafka topics. Existing blueprint inputs retain their defaults for backward compatibility. visibleWhen supports selective input capture, and named string parameters flow into child-blueprint evaluation.

The process deployment generator uses those capabilities to create the server, worker projects, worker JARs, and optional service-registry host according to the process definitions and selected topology. Generated artifacts gained startup/readme guidance and an H2 console for local development.

Parent dependency management added the shared outbox and split crontab artifacts, and removed the retired process-utils dependency. The flattened parent POM was corrected so the published Chenile parent version continues to resolve through child POMs.

See the 2.1.33 release notes and the JGen blueprint reference.

2.1.34: typed workers and reliable Kafka delivery

Reusable worker generation and typed results

The chenile-process-worker-set blueprint owns generation of one worker API and service JAR per process definition. The process-management blueprint composes it instead of duplicating the per-definition loop. A shared concrete worker service handles listener dispatch; generated worker modules no longer need duplicate service implementations.

Each process type has a typed output contract. Leaf process definitions can declare output fields, and non-leaf outputs contain a typed list of the immediate children’s output type. AggregatedResult<ChildOutput> provides a shared child-output list and error collection in process-delegate, leaving the executor responsible for producing output and the aggregator responsible for collecting child results.

Kafka retry, dead letters, and headers

Worker failures now propagate to Chenile Kafka’s bounded consumer retry handling. After configured attempts are exhausted, the message goes to the dead-letter topic (by default the original topic with .DLT appended). The generated listener is headless and does not publish itself to the service registry.

The queue-based starter forwards only x--prefixed headers with worker messages, allowing application and tenant context to cross JVM boundaries without leaking internal transport properties. Kafka publishing can optionally wait for broker acknowledgement through pubsub.publish.waitTime; the default is 0, which preserves fire-and-forget behavior.

HTTP and cron improvements

Chenile services can return response headers through both HTTP adapters, and multiple URL mappings are supported with backward-compatible metadata. This removes special Location header handling from the trigger controller.

The process UI can use a cron-expression builder to help people create schedules, while direct cron entry remains available. Generated process output also includes API jars owned by the worker blueprint, process-result examples, and launch instructions for the server and workers.

See the 2.1.34 release notes, process deployment tutorial, and process administration guide.

Upgrade considerations across the range

• Upgrade Chenile modules together under the matching chenile-parent version. Do not mix artifacts from different release trains.
• Numeric identifiers are opt-in. Keep existing String identifiers unless an application-owned schema migration is planned.
• Query Catalog, alternate workflow stores, Azure routing, and logical handlers are opt-in features. Apply the Query Catalog schema only when enabling it.
• Process-management contracts changed substantially after 2.1.31. Review process definition fields, predecessor behavior, trigger acknowledgement, durable outbox delivery, worker queue configuration, and deployed database schema before upgrading an existing installation.
• Generated process deployments should be regenerated or reviewed against the matching JGen and runtime versions. Implement generated worker business logic in the designated executor; the framework does not invent application behavior.
• pubsub.publish.waitTime defaults to 0. Configure a positive value only when the publisher must wait for broker acknowledgement.

Per-version notes

• 2.1.29
• 2.1.30
• 2.1.31
• 2.1.33
• 2.1.34