flowable/flowable-engine · error · FlowableException

Could not lookup beanmanager in jndi. If no jndi is availabl

Error message

Could not lookup beanmanager in jndi. If no jndi is available, set the beanmanger to the 'localInstance' property of this class.

What it means

BeanManagerLookup.lookupBeanManagerInJndi() throws FlowableException after all standard JNDI lookups fail: the explicitly configured name (if any), java:comp/BeanManager (application server) and java:comp/env/BeanManager (servlet container) all raised NamingException. The message instructs users to provide the BeanManager via the static localInstance property instead.

Source

Thrown at modules/flowable-cdi/src/main/java/org/flowable/cdi/impl/util/BeanManagerLookup.java:60

                throw new FlowableException("Could not lookup beanmanager in jndi using name: '" + jndiName + "'.", e);
            }
        }

        try {
            // in an application server
            return (BeanManager) InitialContext.doLookup("java:comp/BeanManager");
        } catch (NamingException e) {
            // silently ignore
        }

        try {
            // in a servlet container
            return (BeanManager) InitialContext.doLookup("java:comp/env/BeanManager");
        } catch (NamingException e) {
            // silently ignore
        }

        throw new FlowableException("Could not lookup beanmanager in jndi. If no jndi is available, set the beanmanger to the 'localInstance' property of this class.");
    }
}

View on GitHub (pinned to d6d39ce1c6)

Solutions

  1. At startup call BeanManagerLookup.setLocalInstance(beanManager) with the BeanManager from your CDI container (e.g. CDI.current().select(BeanManager.class).get()).
  2. Remove flowable-cdi if CDI is not used in the deployment.
  3. Install/ correctly configure the CDI provider (Weld servlet initializer, beans.xml) so the standard JNDI names exist.
  4. If a custom JNDI name is valid in your container, set BeanManagerLookup.setJndiName(...) to it so the lookup succeeds.

Example fix

// before: engine boots in a test with no CDI in JNDI
// after
BeanManagerLookup.setLocalInstance(CDI.current().select(BeanManager.class).get());
Defensive patterns

Strategy: fallback

Validate before calling

try {
    new javax.naming.InitialContext().lookup("java:comp/BeanManager");
} catch (javax.naming.NamingException e) {
    // no JNDI CDI binding: set local instance before engine use
    BeanManagerLookup.setLocalInstance(CDI.current().select(BeanManager.class).get());
}

Type guard

boolean jndiHasBeanManager() {
    try { new javax.naming.InitialContext().lookup("java:comp/BeanManager"); return true; }
    catch (javax.naming.NamingException e) { return false; }
}

Try / catch

try {
    bm = BeanManagerLookup.getBeanManager();
} catch (org.flowable.common.engine.api.FlowableException e) {
    bm = CDI.current().select(BeanManager.class).get();
}

Prevention

When it happens

Trigger: getBeanManager() runs in an environment without CDI bindings in JNDI — plain Java SE, Spring Boot, unit tests, or a servlet container without a working CDI provider — and no localInstance was set.

Common situations: Running flowable-cdi in tests without an app server; Spring Boot apps including CDI modules; servlet container where Weld wasn't registered so java:comp/env/BeanManager is absent.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors


AI-assisted analysis of flowable/flowable-engine@d6d39ce1c6 (2026-09-11). Data as JSON: /api/errors/e46fc9bb0261d248. Report an issue: GitHub.