Intermittent EmptyStackException during CDI bean resolution with Weld and asynchronous jobs

Start with modules/flowable-cdi/src/main/java/org/flowable/cdi/impl/el/CdiResolver.java and compare its context reuse with Weld's AbstractWeldELResolver.lookup behavior described in the issue. Check the CDI integration's resolver registration and tests for asynchronous expression evaluation; the issue does not name a test file. Done means establishing whether shared context causes the failure and, if confirmed, providing a safe fix that preserves CDI lifecycle semantics and avoids leaving duplicate resolvers active.

Describe the bug

We encounter intermittent EmptyStackExceptions when Flowable's asynchronous job executor evaluates service-task expressions using CDI beans on WildFly.

An affected expression is:

#{myBean.myMethod()}

The relevant stacktrace is:

ERROR [org.flowable.job.service.impl.asyncexecutor.DefaultAsyncRunnableExecutionExceptionHandler] (flowable-async-job-executor-thread-2513) {} Job 342851998 failed: 
org.flowable.common.engine.api.FlowableException: Error while evaluating expression: #{myBean.myMethod()}
...
Caused by: java.util.EmptyStackException
    at java.base/java.util.Stack.peek(Stack.java:103)
    at org.jboss.weld.module.web.el.AbstractWeldELResolver.lookup(AbstractWeldELResolver.java:109)
    at org.jboss.weld.module.web.el.AbstractWeldELResolver.getValue(AbstractWeldELResolver.java:83)
    at org.flowable.cdi.impl.el.CdiResolver.getValue(CdiResolver.java:97)
    at org.flowable.common.engine.impl.javax.el.CompositeELResolver.getValue(CompositeELResolver.java:243)
    at org.flowable.common.engine.impl.de.odysseus.el.tree.impl.ast.AstIdentifier.eval(AstIdentifier.java:95)
    at org.flowable.common.engine.impl.de.odysseus.el.tree.impl.ast.AstMethod.eval(AstMethod.java:84)
    at org.flowable.common.engine.impl.de.odysseus.el.tree.impl.ast.AstMethod.eval(AstMethod.java:107)
    ...

The outer stacktrace includes ServiceTaskExpressionActivityBehavior.execute() and ExecuteAsyncRunnable.executeJob().

MyBean is a @Named implicit @Dependent Bean

Suspected cause

In the CdiResolver implementation we inspected, an internal EL context is created in the constructor and stored as an instance field. Subsequent calls pass this same context to the CDI container's EL resolver:

getWrappedResolver().getValue(this.context, base, property);

The https://jakarta.ee/specifications/platform/11/apidocs/jakarta/el/elcontext explicitly states that ELContext is not thread-safe and should never be shared between threads. This makes the reuse of the internal context a potential concurrency issue if the same CdiResolver instance is used by multiple asynchronous job executor threads.

Weld stores its ELCreationalContextStack in that context. In Weld 6.0.4.Final, the failing line is stack.peek().get() in the @Dependent bean lookup branch.

Our hypothesis is that concurrent calls using the same CdiResolver instance share this stack. One lookup could remove an entry while another lookup is still using it, resulting in the exception.

This is currently a hypothesis based on the stacktrace and source inspection; we have not demonstrated the precise thread interleaving.

Expected behavior

Concurrent asynchronous jobs should resolve CDI beans without EmptyStackExceptions. Evaluation state should be isolated appropriately while preserving CDI scope and bean lifecycle semantics.

Code

We are considering the following workaround, which creates a fresh Flowable CdiResolver for each resolver method call:

import java.beans.FeatureDescriptor;
import java.util.Iterator;

import org.flowable.cdi.impl.el.CdiResolver;
import org.flowable.common.engine.impl.javax.el.ELContext;
import org.flowable.common.engine.impl.javax.el.ELResolver;

public final class IsolatedCdiResolver extends ELResolver {

    @Override
    public Object getValue(ELContext context, Object base, Object property) {
        return new CdiResolver().getValue(context, base, property);
    }

    @Override
    public Class<?> getType(ELContext context, Object base, Object property) {
        return new CdiResolver().getType(context, base, property);
    }

    @Override
    public void setValue(
            ELContext context, Object base, Object property, Object value) {
        new CdiResolver().setValue(context, base, property, value);
    }

    @Override
    public boolean isReadOnly(
            ELContext context, Object base, Object property) {
        return new CdiResolver().isReadOnly(context, base, property);
    }

    @Override
    public Iterator<FeatureDescriptor> getFeatureDescriptors(
            ELContext context, Object base) {
        return new CdiResolver().getFeatureDescriptors(context, base);
    }

    @Override
    public Class<?> getCommonPropertyType(ELContext context, Object base) {
        return new CdiResolver().getCommonPropertyType(context, base);
    }

    @Override
    public Object invoke(
            ELContext context,
            Object base,
            Object method,
            Class<?>[] paramTypes,
            Object[] params) {
        return new CdiResolver().invoke(
                context, base, method, paramTypes, params);
    }
}

CdiJtaProcessEngineConfiguration processEngineConfiguration = new CdiJtaProcessEngineConfiguration();
processEngineConfiguration.setPreDefaultELResolvers(List.of(new IsolatedCdiResolver()));

This should provide each call with a separate internal EL context and therefore a separate Weld creational-context stack.

The workaround has not yet been activated in the affected environment, so we cannot report that it resolves the observed failures.

Additional context

Environment:

• Flowable version: 7.2.0
• WildFly version: 41.0.1
• Weld version: 6.0.4.Final
• Java version: 25
• Integration: Flowable CDI integration on WildFly (CdiJtaProcessEngineConfiguration), with the asynchronous job executor enabled.

Before applying the workaround, we would appreciate clarification on the following:

1. Does the suspected sharing of the internal EL context explain this failure, and should this be fixed in Flowable's CDI integration?
2. Is creating a fresh CdiResolver for every resolver method call a safe workaround? In particular, could it affect @Dependent bean creation/destruction, reuse of a named dependent bean within a single expression evaluation, or context state needed across resolver calls?
3. What is the recommended way to replace the built-in CDI resolver so that the original resolver does not remain active alongside this wrapper? Would you recommend a different workaround?

Relevant references:

• https://github.com/flowable/flowable-engine/blob/flowable-7.2.0/modules/flowable-cdi/src/main/java/org/flowable/cdi/impl/el/CdiResolver.java
• https://github.com/weld/core/blob/6.0.4.Final/modules/web/src/main/java/org/jboss/weld/module/web/el/AbstractWeldELResolver.java
• https://jakarta.ee/specifications/platform/11/apidocs/jakarta/el/elcontext

(created with ChatGPT)