Flowable resolves to wrong bean instances when running muliple tests

We have a master flow that manages a number of sub flows. The subflows are seperate bpmn flows that are called through CallActivity.

The sub flow has interactions with other systems, and updates a database record with the results.

We need a number of scenario tests (maven integration tests) for the master flow, during which the subflows are called. To make the tests more managable, we replace the actual flow with a test flow that has a task where we can insert the end results we want from the flow.For this test flow we can register callables that will be called when the flow executes (we store the callables in a list in the bean and use them one after each other when the activity java code is called).

In activiti this worked fine.

In flowable it works if you only run this test (reliably, done it a huge number of times)

However, if we run the full test suite the test fails.

What we found after quite some searching and adding logs etc.is that the registered callables were not called, resulting in the test failing. In stead the default behavior encoded was called (a strong point against default behavior for test classes). We could not find any coding error, so we added logging statements to all bean operations that show the operation name and the hashcode of the bean.

This showed the following:

  1. The flowable process uses the bean that is created when we start the tests (so it uses the initial application context or it somehow caches the bean internally).
  2. The test uses the bean that is created most recently. In tests beans get recreated as the application for all tests is not the same. (We also log this info from the constructor)

As the test and flow use different beans, the configuration done by the test is not picked up by the flow.

We have tried to a number of work arounds to enforce singleton behaviour:

  1. Tried to enforce only one application context for all tests, but we were not able enforce this.

  2. Moved from a scanned bean to using a TestConfiguration with a bean factory method that always returned the same instance. The bean could then not be found by the flow, but it was wired into the test, not even when we qualified it with the correct names.
    Question: Is there a reason beans are picked up from test code using scanning, but not from TestConfigurations (the test configuration is imported in the application context with @Import

  3. We made the state static within the bean, so all beans share the state. This works, at least in this case.

We are using the SpringBeanFactoryProxyMap:
configuration.setBeans(new SpringBeanFactoryMap(configuration.getApplicationContext());

However, we really would like to know why the flowable process doesn’t pick up the bean from the latest application context during testing, as we suspect that further on in the migration process we might run into similar issues that might not be easily fixable

Hey @W.Veldhuis,

How are you creating the Flowable engines in your tests? Are you using Spring Boot or you are manually creating the engines? Which engines are you using?

Initially it looks like you are getting wrong Flowable Engine instance when you have different Application Contexts. I have some ideas for this, but I would like to know what your setup is first.

When you are using TestConfiguration you will have different bean instances, so this should work properly with different Engine instances in the application context.


Sorry for the late reply.

Due to a company decision, we had to stop development on flowable related tasks, and we have to go back to the activity flows.

We are creating the engine with spring boot, but are not recreating the engine for tests. So we depend on the bean creation as done in production code. Apparently in a new test context this is not done again. We do have TestConfiguration annotated classes, but these are mainly for rewiring camel flows and specific test related beans.

Due to quite high workload I will not be able to follow up this problem at the moment. It is uncertain we will be able to go back to this code at a later stage, but at the moment that seems unlikely.