flowable/flowable-engine · error · FlowableException

problem resolving scripting engine:

Error message

problem resolving scripting engine: 

What it means

OsgiJSR223FlowableScriptEngine.getEngineByName delegates script engine resolution to Extender.resolveScriptEngine, which can throw InvalidSyntaxException (from the OSGi LDAP filter/service tracker machinery). Flowable wraps it in a FlowableException('problem resolving scripting engine: <message>') so script task execution fails with a Flowable-specific exception. If resolution simply returns null, the superclass default lookup is used instead.

Source

Thrown at modules/flowable-osgi/src/main/java/org/flowable/osgi/OsgiJSR223FlowableScriptEngine.java:32

import javax.script.ScriptEngine;

import org.flowable.common.engine.api.FlowableException;
import org.flowable.common.engine.impl.scripting.JSR223FlowableScriptEngine;
import org.osgi.framework.InvalidSyntaxException;

/**
 * @author Filip Hrisafov
 */
public class OsgiJSR223FlowableScriptEngine extends JSR223FlowableScriptEngine {

    @Override
    protected ScriptEngine getEngineByName(String language) {
        ScriptEngine scriptEngine = null;
        try {
            scriptEngine = Extender.resolveScriptEngine(language);
        } catch (InvalidSyntaxException e) {
            throw new FlowableException("problem resolving scripting engine: " + e.getMessage(), e);
        }

        if (scriptEngine == null) {
            return super.getEngineByName(language);
        }

        return scriptEngine;
    }
}

View on GitHub (pinned to d6d39ce1c6)

Solutions

1. Check the chained cause (InvalidSyntaxException) for the exact invalid filter string
2. Fix the script engine name/registration so the derived OSGi filter is valid LDAP syntax
3. Ensure the script engine bundle is deployed and its factory is correctly registered
4. If the engine is intentionally unavailable, rely on the default lookup by using a standard language name (e.g. 'javascript', 'groovy')

Example fix

// before
// engine registered with name "my engine (v2)" -> invalid LDAP filter chars
// after
// register the factory with a simple name
factory.getNames().add("myengine"); // no parentheses/spaces

// validate the language name before requesting an engine
if (language == null || language.matches(".*[()&=!<>].*")) {
    throw new IllegalArgumentException("Script language name breaks OSGi filter syntax: " + language);
}

try {
    scriptEngine.eval(script, bindings);
} catch (FlowableException e) {
    if (e.getMessage() != null && e.getMessage().startsWith("problem resolving scripting engine")) {
        logger.warn("Falling back: cannot resolve script engine", e);
        // use default engine lookup or a supported language
    } else {
        throw e;
    }
}

When it happens

Trigger: Executing a script task (or otherwise requesting an engine by name) while the OSGi service tracker filter used by Extender.resolveScriptEngine is syntactically invalid, causing InvalidSyntaxException; typically due to a bad engine-name-derived filter or misconfigured scripting engine registration.

Common situations: Custom script engine names containing characters that break LDAP filter syntax; misconfigured script engine service registration in the OSGi container; requesting a scripting language before its engine bundle is registered.

Understand the failure class

Background: "not installed", "pip install", "required for": how missing-dependency errors surface across open-source libraries — this error's family across 34 libraries.

Related errors

• Invalid ScriptEngineFactory:
• Cannot create ScriptEngineFactory: {}
• '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/253c8ebdb7bc53ee. Report an issue: GitHub.