Spring boot flowable errors

I have been attempting to run the flowable-spring-boot-sample-basic test project.

The application starts and runs, however I see this issue in the console within IntelliJ.

A NullPointerException in flowable-acquire-async-jobs.

Am I missing something in configuration?

2017-01-16 17:28:28.509 INFO 6048 — [ main] o.f.engine.impl.ProcessEngineImpl : ProcessEngine default created
Exception in thread “flowable-acquire-async-jobs” java.lang.NullPointerException
at org.flowable.engine.impl.asyncexecutor.DefaultAsyncJobExecutor.getRemainingCapacity(DefaultAsyncJobExecutor.java:254)
at org.flowable.engine.impl.asyncexecutor.AcquireAsyncJobsDueRunnable.run(AcquireAsyncJobsDueRunnable.java:53)
at java.lang.Thread.run(Thread.java:745)
2017-01-16 17:28:28.521 INFO 6048 — [ main] o.f.e.i.a.AbstractAsyncExecutor : Starting up the async job executor [org.flowable.spring.SpringAsyncExecutor].
2017-01-16 17:28:28.522 INFO 6048 — [ Thread-3] o.f.e.i.a.AcquireAsyncJobsDueRunnable : {} starting to acquire async jobs due
2017-01-16 17:28:28.522 INFO 6048 — [ Thread-4] o.f.e.i.a.AcquireTimerJobsRunnable : {} starting to acquire async jobs due
2017-01-16 17:28:28.522 INFO 6048 — [ Thread-5] o.f.e.i.a.ResetExpiredJobsRunnable : {} starting to reset expired jobs
2017-01-16 17:28:29.145 INFO 6048 — [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup
2017-01-16 17:28:29.776 INFO 6048 — [ main] flowable.Application : Started Application in 5.253 seconds (JVM running for 5.963)

Have started trying some of the other sample apps. The flowable-spring-boot-sample-jpa also has issues.

When running the Junit ProcessEngineAutoConfigurationTest it works successfully.

However, when attempting to actually run the application, I see two errors.

One is the same NullPointer listed above.

The second is:

Caused by: org.flowable.engine.common.api.FlowableException: Query return 3 results instead of max 1
at org.flowable.engine.impl.AbstractQuery.executeSingleResult(AbstractQuery.java:184)
at org.flowable.engine.impl.AbstractQuery.execute(AbstractQuery.java:161)
at org.flowable.engine.impl.interceptor.CommandInvoker$1.run(CommandInvoker.java:39)
at org.flowable.engine.impl.interceptor.CommandInvoker.executeOperation(CommandInvoker.java:80)
at org.flowable.engine.impl.interceptor.CommandInvoker.executeOperations(CommandInvoker.java:59)
at org.flowable.engine.impl.interceptor.CommandInvoker.execute(CommandInvoker.java:44)
at org.flowable.engine.impl.interceptor.TransactionContextInterceptor.execute(TransactionContextInterceptor.java:51)
at org.flowable.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:64)
at org.flowable.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:47)
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:133)
at org.flowable.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:45)
at org.flowable.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:30)
at org.flowable.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:44)
at org.flowable.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:39)
at org.flowable.engine.impl.AbstractQuery.singleResult(AbstractQuery.java:124)
at flowable.PhotoService.launchPhotoProcess(Application.java:82)

I have tried these two spring boot applications on Activity 5.22 and both run successfully.


about the two issues;

The first; the NPE; did you make any modifications that could be causing this? When I run the latest code the sample-basic runs without throwing a NPE.

The second; there was an issue with the BPMN XML. The subprocess did not include an end event. I fixed it and pushed it to the repo.



I looked through github last night and it seems that the NPE issue should be resolved in the next RC by

I was just a little taken aback, because in both sample projects the unit tests passed successfully, but actually running the Spring Boot app has issues. The unit tests might need to be improved in this area.


I was assuming you were on the latest master revision of the code. The fix you are referring to is in there.

You’re right. The unit tests can be improved. We’re always open to a PR :wink: