bpm: a flowable:class execution or task listener reaches the client bean container too (#7222)

[delchev]

Cause

#7189 (#7058) wires a client JavaDelegate through the bean container on both service-task paths, but BpmFlowableConfig registered only the activity-behaviour factory. Flowable creates a listener through a different one: ProcessEngineConfigurationImpl.initListenerFactory builds its own DefaultListenerFactory carrying a stock DefaultClassDelegateFactory, and createClassDelegateExecutionListener / createClassDelegateTaskListener call that.

So a <flowable:executionListener class="..."> or <flowable:taskListener class="..."> written the way the new docs teach — a constructor collaborator, or an @Inject field — either failed at reflection (no no-arg constructor) or ran with every injected field null, silently. That is the #7058 symptom one artefact type over, and it made ResilientClassDelegateFactory.create(String, List) — the overload the listener path uses — dead code under this configuration.

Change

BpmFlowableConfig additionally registers setListenerFactory(new DefaultListenerFactory(classDelegateFactory)) with the same factory instance, so both listener kinds come out as ResilientClassDelegates and share instantiateDelegate, the client-bean seam. The engine keeps a pre-set listener factory and only injects the expression manager into it, so expression listeners are unaffected and nothing else about the engine changes.

A listener deliberately gets no intent step resilience: execute() is the service-task entry point and Flowable's notify paths never reach it — a listener is not a step, and nothing in the DSL emits one.

The two doc sentences the issue flags (ResilientClassDelegate's javadoc and engine-java/CLAUDE.md) said the seam covered every flowable:class delegate; they now say what it covers and why the listener needed a second registration, in engine-java/CLAUDE.md and engine-intent/CLAUDE.md.

Verification

• New ResilientListenerFactoryTest — against a real (in-memory) engine: both listener kinds come out as ResilientClassDelegates, the configured factory survives initListenerFactory and gets its expression manager, and the defect case is pinned alongside (without the registration the listener is a stock ClassDelegate).
• engine-bpm-flowable unit suite — 38 tests, green.
• JavaDelegateInjectionIT gains a listener process (listeners.bpmn + a constructor-injected ExecutionListener and an @Inject-field TaskListener). All 4 tests green with the fix; the new one fails without it with couldn't instantiate class delegateinjection.CtorInjectedExecutionListener / NoSuchMethodException: <init>() — checked by reverting the one production line and re-running.
• mvn formatter:validate over the reactor with the cache wiped, and the release-profile javadoc build on engine-bpm-flowable.

Not run locally: the rest of the IT suite.

One adjacent fix rode along, because the new assertion needed it: the IT's runtime-variable helpers were querying variableName, which is the historic endpoint's key — the runtime endpoint serves Flowable's own variable entities, whose key is name. That made assertNoRuntimeVariable vacuous.

Fixes #7222

🤖 Generated with Claude Code