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
- At startup call BeanManagerLookup.setLocalInstance(beanManager) with the BeanManager from your CDI container (e.g. CDI.current().select(BeanManager.class).get()).
- Remove flowable-cdi if CDI is not used in the deployment.
- Install/ correctly configure the CDI provider (Weld servlet initializer, beans.xml) so the standard JNDI names exist.
- 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
- In SE/ test/ Spring environments always set BeanManagerLookup.setLocalInstance at boot.
- Install the CDI provider (Weld initializer) when running in servlet containers.
- Remove flowable-cdi from non-CDI deployments.
- Do a startup sanity lookup of java:comp/BeanManager to fail fast.
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
- Could not lookup beanmanager in jndi using name: '${jndiName
- No cdi bean manager available, cannot publish event.
- No cdi bean manager available, cannot publish event.
- Cannot use this method of the BusinessProcess bean within an
- Cannot use startProcessByName in an active command.
AI-assisted analysis of flowable/flowable-engine@d6d39ce1c6 (2026-09-11).
Data as JSON: /api/errors/e46fc9bb0261d248.
Report an issue: GitHub.