Found Flowable 5 process definition, but no compatibility handler on the classpath


In the holiday request example in the manual, if I try and access the current flow element for a process instance I get the following exception:

Exception in thread "main" org.flowable.engine.common.api.FlowableException: Found Flowable 5 process definition, but no compatibility handler on the classpath
	at org.flowable.engine.impl.util.Flowable5Util.getFlowable5CompatibilityHandler(
	at org.flowable.engine.impl.util.ProcessDefinitionUtil.getProcess(
	at org.flowable.engine.impl.persistence.entity.ExecutionEntityImpl.getCurrentFlowElement(

The Context.getProcessEngineConfiguration() call seems to return null.

I have a similar problem with getIdentityLinks() on a task where I get a NullPointerException because the Context.getCommandContext() returns null.

Do you have the v5 compatibility enabled? See

Thanks for the reply, but just as background I am new to flowable and have no legacy processes and therefore no need for version 5 compatibility.

I worked through the “Getting Started” section holiday request example in the manual, which makes no reference to needing version 5 compatibility.

I have worked through the v6 migration guide to find clues, but I am not able to determine what I am doing that makes it think I want to use version 5. The code seems to allow for two execution paths, and the version 6 one doesn’t seem to want to execute due to the Context static calls failing and I am not sure where the framework initializes those.

Sorry for the confusion. Indeed, you should not need to have compatibility jars on the classpath if you’re simply running the getting started against v5.

Where are you calling this getCurrentFlowElement()? It only works while doing an API call or in a JavaDelegate (ie a context must be active). If you call this (after casting I assume, it should not be accessible by default in the returned interface) outside of an API call, it will throw an exception as currently no exception is going on.

So, what’s the code your’e executing that throws this exception?

That being said, I agree the exception being thrown is not correct, it should not mention anything about v5 in this case. I made a small tweak to improve this here:

Thanks, here is a minimal piece of code that runs into the problem:

    ProcessEngineConfiguration cfg = new StandaloneProcessEngineConfiguration()
    ProcessEngine processEngine = cfg.buildProcessEngine();
    RepositoryService repositoryService = processEngine.getRepositoryService();
    Deployment deployment = repositoryService.createDeployment().addClasspathResource("holiday-request.bpmn20.xml")
    RuntimeService runtimeService = processEngine.getRuntimeService();
    ProcessInstance processInstance = runtimeService.startProcessInstanceByKey("holidayRequest");

The holiday request xml from here:

If I run this after cfg.buildProcessEngine() then I get a null answer:
(ProcessEngineConfigurationImpl) processEngine.getProcessEngineConfiguration());

But the following call now works which didn’t before (also got the same exception):
org.flowable.bpmn.model.Process p = ProcessDefinitionUtil.getProcess(processInstance.getProcessDefinitionId());

Note I have the same problem in a CDI environment deployment on WildFly connecting to postgres flowable database…

This line


won’t work when called standalone like here, it only works for example in the JavaDelegate. Furthermore, a process instance won’t ever have a ‘current flow element’, the child executions will have one, but the process instance itself not.

However, imho, the process instance (via the Execution) should not expose getCurrentFlowelement() as a method. This should be on the DelegateExecution only. I’ll investigate why this is exposed this way.

If you want to know what activities currently are active for a process instance, you can use for example the historyService.createHistoricActivityInstanceQuery, providing the process instance id.

Thanks, I will go read up on the concepts of JavaDelegate’s and child executions.

FYI: to avoid confusion, the getCurrentFlowElement() was removed from the Execution interface: