flowable/flowable-engine · warning
Cannot create ScriptEngineFactory: {}
Error message
Cannot create ScriptEngineFactory: {} What it means
During script engine resolution, the OSGi Extender instantiates discovered ScriptEngineFactory implementations to check their engine name. Any exception during factory instantiation (missing classes, wiring failures, factory bugs) results in this warning and the engine is skipped for that lookup.
Source
Thrown at modules/flowable-osgi/src/main/java/org/flowable/osgi/Extender.java:404
if (test.equals(name)) {
ClassLoader old = Thread.currentThread().getContextClassLoader();
ScriptEngine engine;
try {
// JRuby seems to require the correct TCCL to call
// getScriptEngine
Thread.currentThread().setContextClassLoader(factory.getClass().getClassLoader());
engine = factory.getScriptEngine();
} finally {
Thread.currentThread().setContextClassLoader(old);
}
LOGGER.trace("Resolved ScriptEngineFactory: {} for expected name: {}", engine, name);
return engine;
}
}
LOGGER.debug("ScriptEngineFactory: {} does not match expected name: {}", factory.getEngineName(), name);
return null;
} catch (Exception e) {
LOGGER.warn("Cannot create ScriptEngineFactory: {}", e.getClass().getName(), e);
return null;
}
}
@Override
public String toString() {
return "OSGi script engine resolver for " + bundle.getSymbolicName();
}
}
}
View on GitHub (pinned to d6d39ce1c6)
Solutions
- Read the attached exception '{}' argument in the log to see the factory class and root cause.
- Install/start the scripting bundle that provides the engine (e.g. org.flowable.osgi-compatible groovy/jython bundles) and its dependencies.
- Verify the engine bundle's OSGi imports resolve: bundle:diag <id> in Karaf.
- Ensure the script engine factory class name listed in META-INF/services/javax.script.ScriptEngineFactory is correct.
Example fix
// before: engine bundle missing transitive deps osgi> start org.python.jython // ClassCastException / LinkageError // after osgi> feature:install jython-scripting osgi> start flowable-osgi-extender
Defensive patterns
Strategy: fallback
Validate before calling
for (Provider<ScriptEngineFactory> p : ServiceLoader.load(ScriptEngineFactory.class)) {
try { p.get(); } catch (Throwable t) {
logger.warn("Unusable script engine factory: {}", p.type().getName());
}
} Type guard
boolean engineUsable(ScriptEngineFactory f) {
try { return f.getEngineName() != null; }
catch (Throwable t) { return false; }
} Prevention
- Install all scripting bundles and their transitive dependencies before starting the extender.
- Run bundle:diag to verify OSGi import resolution for engine bundles.
- Verify META-INF/services/javax.script.ScriptEngineFactory entries point to valid classes.
When it happens
Trigger: resolveScriptEngine (called from resolvedEngine) calls factory.getEngineName() after instantiating a ScriptEngineFactory whose class throws on construction or whose Class.forName fails with a non-Error exception.
Common situations: A scripting bundle (e.g. Jython, Groovy, Nashorn) is present but its engine factory cannot be wired in OSGi due to missing imported packages or a broken fragment; script engine bundle started in wrong order.
Related errors
- Invalid ScriptEngineFactory:
- problem resolving scripting engine:
- 'language' evaluated to null for taskListener of type 'scrip
- Script content is null or evaluated to null for taskListener
- The field 'script' should be set on the TaskListener
AI-assisted analysis of flowable/flowable-engine@d6d39ce1c6 (2026-09-11).
Data as JSON: /api/errors/6ab87a3d5f8bbd95.
Report an issue: GitHub.