camunda / camunda-bpm-spring-boot-starter

Camunda BPM bootified!

Deprecated

This repository moved here: https://github.com/camunda/camunda-bpm-platform/tree/master/spring-boot-starter

camunda-bpm-spring-boot-starter

This project provides Spring Boot starters that allow you to integrate the Camunda BPM Platform into your Spring Boot applications.

Please check out the Documentation, the Getting Started Guide and the Examples.

Resources

• Issue Tracker - if you have an idea for a new feature or want to file a bug …​ this is the place to go.

• Contributing - check this if you want to contribute

• Discussion Forum - this project has it’s own sub-category at the camunda forum …​ use it!

JDK 9 and onwards

Beginning with version 3.1-alpha2, Camunda Spring Boot Starter can be used in conjunction with JDK 9 / 10. As Hibernate is part of Camunda Spring Boot Starter it requires JAXB. However, JAXB is deactivated by default (and marked as deprecated) in JDK 9 / 10 and removed entirely in JDK 11. Therefore, it is sensible to re-add JAXB to your Camunda Spring Boot Starter project.

There exist various implementations of JAXB. The following Maven coordinates represent the implementation which is included in the JDKs up to version 10:

<dependency>
  <groupId>com.sun.xml.bind</groupId>
  <artifactId>jaxb-impl</artifactId>
</dependency>

Resources for versions older than 2.3.0

Before version 2.2.0, the project existed as a community extension. Therefore the resources were located in different paths. You can find all the links below.

• Issue Tracker - please DON’T create new issues here.

• Documentation

2.x

• Release Notes 2.2.0

• Release Notes 2.1.2

• Release Notes 2.1.0

• Release Notes 2.0.0

1.3.0

• Release Notes 1.3.0

Migration hints from < 1.3.0 to >= 1.3.0

Important

We have decided to refactor the configuration mechanism. Especially, we removed the org.camunda.bpm.spring.boot.starter.configuration.CamundaConfiguration interface. For now, each configuration is a org.camunda.bpm.engine.impl.cfg.ProcessEnginePlugin. With this it is possible to hook into preInit, postInit and postProcessEngineBuild, which supports more complex situations. If you have implemented a CamundaConfiguration, you have to switch to ProcessEnginePlugin (and its preInit method). You can also extend your configuration from org.camunda.bpm.spring.boot.starter.configuration.impl.AbstractCamundaConfiguration to avoid a cast to SpringProcessEngineConfiguration.

1.2.1

• Release Notes 1.2.1

• Blog Article for release 1.2.0

Credits

The Camunda Spring Boot Starter project used to be the community extension, created and supported by

• Oliver Steinhauer

• Jan Galinski

• Christian Lipphardt

Starting from version 2.3.0 it was adopted as part of the Camunda BPM Platform.

License

• The source files in this repository are made available under the Apache License, Version 2.0.

camunda-bpm-spring-boot-starter's Issues

set up continuous integration

we should have automated builds and snapshot repos

switch to spring-boot 1.3

Here are the release note: https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-1.3-Release-Notes

Imo this is something we should use from now on.

Multiple camunda-spring-boot apps can connect to a single database

For this to work, we must register the deployment (PA) and configure the job executor accordingly so the jobExecutorDeploymentAware flag is working correctly.

set up maven multi module project

I like that we keep the starters really small, focussed and stackable.
But I'd prefer having a classic maven multi module set up like this:

/pom.xml - root pom for project
/starter/pom.xml
/starter-cockpit/pom.xml
/examples/pom.xml - examples root
/examples/simple/pom.xml
/examples/web/pom.xml

That way the hierarchical structure of the modules reflects the folder structure, it is possible to build all modules with one build and we do not have to define dependencies over and over again.

This is related to #2.

easy and clean support for camunda REST api via starter

The current starter supports adding the REST API controllers. The setup is very complicated, there are a lot of dependencies I have to add to my pom to activate this and even then it is not perfectly clear how it all works together and how I can configure it. (see also #20)

Maybe we can find a simpler way by offering a dedicated "starter-rest" that bundles the usual dependencies to run server+api?

Also we should investigate if we can get rid of the jboss/resteasy dependency, doesn't seem to be very "springy" in my opinion ...

consequent usage of slf4j logging

I noticed that the starter still uses jul while examples and tests use slf4j-api. We should be strict here and switch to slf4j completely.

This applies to the following files:

camunda-bpm-spring-boot-starter# find . -name *.java | xargs grep -l "import java.util.logging" 
    ./extension/camunda-spring-boot-starter/src/main/java/org/camunda/bpm/spring/boot/starter/CamundaBpmConfiguration.java
    ./extension/camunda-spring-boot-starter-rest/src/main/java/org/camunda/bpm/spring/boot/starter/rest/CamundaJerseyResourceConfig.java
    ./extension/camunda-spring-boot-starter-rest/src/test/java/my/own/custom/spring/boot/project/SampleCamundaRestApplication.java

Create getting started guide for camunda.org

stand alone example projects

I want the examples to be standalone, so that when I want to build a project of my own based on the starters, I can basically copy the example and start working ...
we shouldn't use any parent dependencies/management, each example is selfcontained.

releated to #23

example-web is not reachable via browser

The ITest works, but when I start the application itself and open http://localhost:8080/engine/default/process-definition I get a 404. Is there something wrong with the starter or am I missing something? I did do any configuration, just started the Application

strange behavior when using 7.4.0 history level auto feature

When using camunda 7.4.0 in conjunction with supported history level auto there is a strange initialization behavior:

Following org.camunda.bpm.engine.spring.ProcessEngineFactoryBean the calls are:

1. org.camunda.bpm.engine.impl.cfg.ProcessEngineConfigurationImpl.init()
2. org.camunda.bpm.engine.impl.SchemaOperationsProcessEngineBuild.determineAutoHistoryLevel(ProcessEngineConfigurationImpl, HistoryLevel)

This results in configuration elements having historyLevel == null and errors when auto deploying:

Caused by: org.camunda.bpm.engine.ProcessEngineException: ENGINE-01009 Error while parsing process
    at org.camunda.bpm.engine.impl.bpmn.parser.BpmnParseLogger.parsingProcessException(BpmnParseLogger.java:46) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.bpmn.parser.BpmnParse.execute(BpmnParse.java:298) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.bpmn.deployer.BpmnDeployer.transformDefinitions(BpmnDeployer.java:100) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.AbstractDefinitionDeployer.transformResource(AbstractDefinitionDeployer.java:91) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.AbstractDefinitionDeployer.parseDefinitionResources(AbstractDefinitionDeployer.java:66) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.AbstractDefinitionDeployer.deploy(AbstractDefinitionDeployer.java:56) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.persistence.deploy.DeploymentCache$1.call(DeploymentCache.java:69) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.persistence.deploy.DeploymentCache$1.call(DeploymentCache.java:66) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.interceptor.CommandContext.runWithoutAuthorization(CommandContext.java:553) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.persistence.deploy.DeploymentCache.deploy(DeploymentCache.java:66) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.persistence.entity.DeploymentManager.insertDeployment(DeploymentManager.java:52) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.cmd.DeployCmd.deploy(DeployCmd.java:470) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.cmd.DeployCmd$1.call(DeployCmd.java:137) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.cmd.DeployCmd$1.call(DeployCmd.java:126) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.interceptor.CommandContext.runWithoutAuthorization(CommandContext.java:553) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.cmd.DeployCmd.doExecute(DeployCmd.java:126) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.cmd.DeployCmd.execute(DeployCmd.java:93) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.cmd.DeployCmd.execute(DeployCmd.java:75) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.interceptor.CommandExecutorImpl.execute(CommandExecutorImpl.java:24) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:95) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:42) ~[camunda-engine-spring-7.4.0.jar:7.4.0]
    at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:133) ~[spring-tx-4.2.3.RELEASE.jar:4.2.3.RELEASE]
    at org.camunda.bpm.engine.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:40) ~[camunda-engine-spring-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:30) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.RepositoryServiceImpl.deploy(RepositoryServiceImpl.java:92) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.repository.DeploymentBuilderImpl.deploy(DeploymentBuilderImpl.java:207) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.spring.SpringProcessEngineConfiguration.autoDeployResources(SpringProcessEngineConfiguration.java:143) ~[camunda-engine-spring-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.spring.SpringProcessEngineConfiguration.buildProcessEngine(SpringProcessEngineConfiguration.java:62) ~[camunda-engine-spring-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.spring.ProcessEngineFactoryBean.getObject(ProcessEngineFactoryBean.java:51) ~[camunda-engine-spring-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.spring.ProcessEngineFactoryBean.getObject(ProcessEngineFactoryBean.java:31) ~[camunda-engine-spring-7.4.0.jar:7.4.0]
    at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:168) ~[spring-beans-4.2.3.RELEASE.jar:4.2.3.RELEASE]
    ... 65 common frames omitted
Caused by: java.lang.NullPointerException: null
    at org.camunda.bpm.engine.impl.history.parser.HistoryParseListener.addActivityHandlers(HistoryParseListener.java:224) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.history.parser.HistoryParseListener.parseStartEvent(HistoryParseListener.java:142) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.bpmn.parser.BpmnParse.parseStartEvents(BpmnParse.java:864) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.bpmn.parser.BpmnParse.parseScope(BpmnParse.java:650) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.bpmn.parser.BpmnParse.parseProcess(BpmnParse.java:574) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.bpmn.parser.BpmnParse.parseProcessDefinitions(BpmnParse.java:513) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.bpmn.parser.BpmnParse.parseRootElement(BpmnParse.java:323) ~[camunda-engine-7.4.0.jar:7.4.0]
    at org.camunda.bpm.engine.impl.bpmn.parser.BpmnParse.execute(BpmnParse.java:288) ~[camunda-engine-7.4.0.jar:7.4.0]
    ... 94 common frames omitted

camunda starter fails in combination with spring-cloud-starter-eureka

If you use the camunda starter together with spring boot eureka, loading the CamundaBpmProperties leads to a NPE.
This is because spring boot eureka uses a parent application context, which does not contain the expected CamundaBpmProperties bean in AbstractFinishedWithNoExceptionRunListener.

As work around, check on null will avoid NPE

Issue while using camunda-bpm-spring-boot-starter

Hi,

I am trying to use camunda bpm spring boot starter in one of my spring boot project through
gradle dependency "org.camunda.bpm.extension:camunda-bpm-spring-boot-starter:1.1.0".

But when i try to start the boot application i see below error
____ _ ____ ____ __ __ / ___| __ _ _ __ ___ _ _ _ __ __| | __ _ | __ )| _ \| \/ | | | / _ | '_ _ \| | | | '_ \ / _ |/ ` | | _ | |) | |/| |
| || (| | | | | | | || | | | | (| | (| | | |_) | __/| | | |
__/,|| || ||,|| ||__,|__,| |/|| || ||

Spring-Boot: (v1.3.1.RELEASE)
Camunda BPM: (v7.4.0)
Camunda BPM Spring Boot Starter: (v1.1.0)

2016-03-04 15:31:23.104 INFO 8660 --- [ main] c.e.a.workflowengine.config.Application : Starting Application on INENHEBBAAL3C with PID 8660 (C:\camunda-scenario-engine\bin started by hebbaa in C:\camunda-scenario-engine)
2016-03-04 15:31:23.119 INFO 8660 --- [ main] c.e.a.workflowengine.config.Application : No active profile set, falling back to default profiles: default
2016-03-04 15:31:24.699 ERROR 8660 --- [ main] o.s.boot.SpringApplication : Application startup failed

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'persistenceExceptionTranslationPostProcessor' defined in class path resource [org/springframework/boot/autoconfigure/dao/PersistenceExceptionTranslationAutoConfiguration.class]: Initialization of bean failed; nested exception is java.lang.IllegalStateException: No persistence exception translators found in bean factory. Cannot perform exception translation.
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:553) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.context.support.PostProcessorRegistrationDelegate.registerBeanPostProcessors(PostProcessorRegistrationDelegate.java:228) ~[spring-context-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.registerBeanPostProcessors(AbstractApplicationContext.java:687) ~[spring-context-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:523) ~[spring-context-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:764) [spring-boot-1.3.1.RELEASE.jar:1.3.1.RELEASE]
at org.springframework.boot.SpringApplication.doRun(SpringApplication.java:357) [spring-boot-1.3.1.RELEASE.jar:1.3.1.RELEASE]
at org.springframework.boot.SpringApplication.run(SpringApplication.java:305) [spring-boot-1.3.1.RELEASE.jar:1.3.1.RELEASE]
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1124) [spring-boot-1.3.1.RELEASE.jar:1.3.1.RELEASE]
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1113) [spring-boot-1.3.1.RELEASE.jar:1.3.1.RELEASE]
at com.emc.adaptivity.workflowengine.config.Application.main(Application.java:11) [bin/:na]
Caused by: java.lang.IllegalStateException: No persistence exception translators found in bean factory. Cannot perform exception translation.
at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.detectPersistenceExceptionTranslators(PersistenceExceptionTranslationInterceptor.java:142) ~[spring-tx-3.1.2.RELEASE.jar:3.1.2.RELEASE]
at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.(PersistenceExceptionTranslationInterceptor.java:79) ~[spring-tx-3.1.2.RELEASE.jar:3.1.2.RELEASE]
at org.springframework.dao.annotation.PersistenceExceptionTranslationAdvisor.(PersistenceExceptionTranslationAdvisor.java:70) ~[spring-tx-3.1.2.RELEASE.jar:3.1.2.RELEASE]
at org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor.setBeanFactory(PersistenceExceptionTranslationPostProcessor.java:103) ~[spring-tx-3.1.2.RELEASE.jar:3.1.2.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeAwareMethods(AbstractAutowireCapableBeanFactory.java:1597) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1565) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
... 14 common frames omitted

2016-03-04 15:31:24.715 WARN 8660 --- [ main] o.c.b.s.b.s.r.JobExecutorRunListener : skipping because of failed context initialization
`

Am i missing any configuration setting?

overwriting camunda.version does not work (in banner)

I am setting up an example project to test the release candidate. My pom defines camunda.version=7.4.0-SNAPSHOT.

But when I start up a simple SpringBoot application, the banner reads "v7.3.0".

I did not check so far whether this is just an issue with the banner or if I am hard-coded to the 7.3 version.

switch job executor on after succesfull boot

It is not a good idea to start the job executor on startup. It should only be started when the engine has been set up correctly.
So when the config requires a job executor, its startup should be postponed till the complete boot server is running.
Once such a tool is in place, it might also allow switching the executor on and off during runtime.

Spring Initializr?

A customer asked me if there are any plans to integrate this into http://start.spring.io/

apply missing parts from community extension blueprint

When you look at https://github.com/camunda/camunda-community-project-blueprint, a few things are missing in this extension (besides optional renaming #5).

• adjust README
• add CONTRIBUTING.md
• add license to pom.xml
• add scm to pom.xml
• add distribution to pom.xml

discussion: introduce flyway for db initialization

It is very likely that you want to do more than just letting camunda create schemas when the server starts. So you need somekind of db-migration. I am working with flyway but had the problem that camundas mybatis lifecycle interferred with my flyway scripts (basically when defining what a baseline is and who touches the db first).
So I came up with camunda-bpm-flyway (currently just a PoC) https://github.com/jangalinski/camunda-bpm-flyway

This small extension reads the db create scripts camunda provides and uses them as flyway migration scripts, so I can easily provide my own custom migrations as well and flyway will use the correct version/combination for all of them.

I found out that spring-boot supports flyway out of the box, so I am raising the question: what do you think of switching the whole "create/drop/update" aspect in camunda-spring-boot to the flyway-way? It is actually very little overhead, since we already have a dataSource centric custom configuration, so just like we do with jobExecutor activation, we could work-around the standard camunda way (by settingschema-updates to false and later migrate via flyway)

Please think about it and give me your feedback. And if you like the idea, we have to decide how and where to implement it ... a ...-flyway-starter seems like the best guess, but then again, some aspects interfere deep with the custom config stuff, so maybe it could be a good idea to decide to make this a core feature.

Excited about your opinions
Jan

NoSuchBeanDefinitionException

Not sure what I'm doing wrong, but if I add the starter as a dependency and try to fire up my application I get this:

org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [org.camunda.bpm.spring.boot.starter.CamundaBpmProperties] is defined
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:372) ~[spring-beans-4.2.2.RELEASE.jar:4.2.2.RELEASE]
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:332) ~[spring-beans-4.2.2.RELEASE.jar:4.2.2.RELEASE]
    at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1060) ~[spring-context-4.2.2.RELEASE.jar:4.2.2.RELEASE]
    at org.camunda.bpm.spring.boot.starter.runlistener.AbstractFinishedWithNoExceptionRunListener.getBean(AbstractFinishedWithNoExceptionRunListener.java:80) ~[camunda-bpm-spring-boot-starter-1.0.0.jar:1.0.0]
    at org.camunda.bpm.spring.boot.starter.runlistener.AbstractFinishedWithNoExceptionRunListener.finished(AbstractFinishedWithNoExceptionRunListener.java:42) ~[camunda-bpm-spring-boot-starter-1.0.0.jar:1.0.0]
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:324) ~[spring-boot-1.2.7.RELEASE.jar:1.2.7.RELEASE]
    at org.springframework.boot.builder.SpringApplicationBuilder.run(SpringApplicationBuilder.java:134) ~[spring-boot-1.2.7.RELEASE.jar:1.2.7.RELEASE]
    at org.springframework.cloud.bootstrap.BootstrapApplicationListener.bootstrapServiceContext(BootstrapApplicationListener.java:126) ~[spring-cloud-context-1.0.2.RELEASE.jar:1.0.2.RELEASE]
    at org.springframework.cloud.bootstrap.BootstrapApplicationListener.onApplicationEvent(BootstrapApplicationListener.java:75) ~[spring-cloud-context-1.0.2.RELEASE.jar:1.0.2.RELEASE]
    at org.springframework.cloud.bootstrap.BootstrapApplicationListener.onApplicationEvent(BootstrapApplicationListener.java:55) ~[spring-cloud-context-1.0.2.RELEASE.jar:1.0.2.RELEASE]
    at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:163) ~[spring-context-4.2.2.RELEASE.jar:4.2.2.RELEASE]
    at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:136) ~[spring-context-4.2.2.RELEASE.jar:4.2.2.RELEASE]
    at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:119) ~[spring-context-4.2.2.RELEASE.jar:4.2.2.RELEASE]
    at org.springframework.boot.context.event.EventPublishingRunListener.publishEvent(EventPublishingRunListener.java:100) ~[spring-boot-1.2.7.RELEASE.jar:1.2.7.RELEASE]
    at org.springframework.boot.context.event.EventPublishingRunListener.environmentPrepared(EventPublishingRunListener.java:59) ~[spring-boot-1.2.7.RELEASE.jar:1.2.7.RELEASE]
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:286) [spring-boot-1.2.7.RELEASE.jar:1.2.7.RELEASE]
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:969) [spring-boot-1.2.7.RELEASE.jar:1.2.7.RELEASE]
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:958) [spring-boot-1.2.7.RELEASE.jar:1.2.7.RELEASE]
    at de.zalando.fulfillment.Application.main(Application.java:14) [classes/:?]
Exception in thread "main" org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [org.camunda.bpm.spring.boot.starter.CamundaBpmProperties] is defined
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:372)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:332)
    at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1060)
    at org.camunda.bpm.spring.boot.starter.runlistener.AbstractFinishedWithNoExceptionRunListener.getBean(AbstractFinishedWithNoExceptionRunListener.java:80)
    at org.camunda.bpm.spring.boot.starter.runlistener.AbstractFinishedWithNoExceptionRunListener.finished(AbstractFinishedWithNoExceptionRunListener.java:42)
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:324)
    at org.springframework.boot.builder.SpringApplicationBuilder.run(SpringApplicationBuilder.java:134)
    at org.springframework.cloud.bootstrap.BootstrapApplicationListener.bootstrapServiceContext(BootstrapApplicationListener.java:126)
    at org.springframework.cloud.bootstrap.BootstrapApplicationListener.onApplicationEvent(BootstrapApplicationListener.java:75)
    at org.springframework.cloud.bootstrap.BootstrapApplicationListener.onApplicationEvent(BootstrapApplicationListener.java:55)
    at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:163)
    at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:136)
    at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:119)
    at org.springframework.boot.context.event.EventPublishingRunListener.publishEvent(EventPublishingRunListener.java:100)
    at org.springframework.boot.context.event.EventPublishingRunListener.environmentPrepared(EventPublishingRunListener.java:59)
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:286)
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:969)
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:958)
    at de.zalando.fulfillment.Application.main(Application.java:14)

Any idea?

rename camunda-cockpit-spring-boot-starter to camunda-webapp-spring-boot-starter

because the starter is for camunda-webapp it should match the name.

Maven repository publishing

By now every module is published (see http://mvnrepository.com/artifact/org.camunda.bpm.extension). Shouldn't only the starter artifacts (camunda-bpm-spring-boot-starter,camunda-bpm-spring-boot-starter-rest,camunda-bpm-spring-boot-starter-webapp) be published?

get rid of resteasy filterdispatcher

replace this

 @Bean
   @ConditionalOnMissingBean(name = "filterDispatcherRegistrationBean")
   public FilterRegistrationBean filterDispatcherRegistrationBean(
     @Qualifier("filterDispatcher") Filter filterDispatcher) {
     FilterRegistrationBean filterRegistrationBean = new FilterRegistrationBean();
     filterRegistrationBean.setName("Resteasy");
     filterRegistrationBean.setFilter(filterDispatcher);
     filterRegistrationBean.addUrlPatterns("/*");
     filterRegistrationBean.addInitParameter("javax.ws.rs.Application",
       RestProcessEngineDeployment.class.getName());
     return filterRegistrationBean;
   }

with something like this

 @Bean
public FilterRegistrationBean jerseyFilterRegistration(
        javax.ws.rs.core.Application eurekaJerseyApp) {
    FilterRegistrationBean bean = new FilterRegistrationBean();
    bean.setFilter(new ServletContainer(eurekaJerseyApp));
    bean.setOrder(Ordered.LOWEST_PRECEDENCE);
    bean.setUrlPatterns(Collections
            .singletonList(EurekaServerConfigBean.DEFAULT_PREFIX + "/*"));

    return bean;
}

so the code has no compile time deps to resteasy any more

job executor configuration - documentation of camunda.bpm.job-execution.enabled missing

While investigating #44 I stumbled upon the test class CamundaNoJobExecutionAutoConfigurationIT

this uses the configuration file: "application-nojobexecution.properties":

camunda.bpm.process-engine-name=testEngine
camunda.bpm.job-execution.enabled=false
camunda.bpm.job-execution.active=true
camunda.bpm.database.schema-update=true
camunda.bpm.history-level=audit

I wonder how camunda.bpm.job-execution.enabled and camunda.bpm.job-execution.active work together here, since camunda.bpm.job-execution.enabled is not documented in the ascii-doc.

I assume that if "enabled==false", "active==true" does not matter anymore. but then again: why would I need two switches here? shouldn't "active" be enough?

Replace spring-boot-parent with camunda-parent

And just import the Spring-Boot parent pom in the dependencyManagement section.
This allows releasing the project to Camunda Nexus and Maven central.

Use Deployment utils from platform-engine to find deployable resources

I found that the current implementation to discover bpmn and cmmn files implemented in https://github.com/camunda/camunda-bpm-spring-boot-starter/blob/master/extension/camunda-spring-boot-starter/src/main/java/org/camunda/bpm/spring/boot/starter/configuration/impl/DefaultDeploymentConfiguration.java does also find packages/directories with that name (org.mydomain.process.bpmn/). I built a filter to check if the forun resource !isDirectory, but this duplicates functionality already implemented in engine.
Also, for the current acm plugin it is required to deploy the cmmn-diagram graphics because there is no js-renderer. This is also already implemented and should be reused.

Conclusion: Do not scan for deployable packages in this starter, re-use utils already present in the engine.

build error after latest commits

After a clean clone and mvn clean package I get

[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] /private/tmp/camunda-spring-boot-starter/camunda-spring-boot-starter/src/test/java/org/camunda/bpm/spring/boot/starter/CamundaAutoConfigurationIT.java:[46,4]     cannot find symbol
  symbol:   class Configuration
  location: class org.camunda.bpm.spring.boot.starter.CamundaAutoConfigurationIT
[INFO] 1 error

spring-boot:run and livereloading of web static assets

I would like to live-reload my web assets as I change them instead of recompiling at each point. My project uses this spring boot starter project and the camunda-bpm-spring-boot-starter-webapp dependency. I have some customized assets that overlay the default webapp assets that currently live in src/main/webapp/* in my project.

I was looking into using the spring-boot-devtools util to enable live-reloading, but I don't think this plays nicely with mvn overlay paradigm. See this recent issue on the matter: spring-projects/spring-boot#1030

I would like to know if this project, or perhaps the camunda webapp project, has any plans to move away from the overlay paradigm. Or is there another way to make livereloading work with either the devtools or some other utility that accomplishes the same thing? Does this project intend to introduce any development tools for developing the webapp further or are there larger changes happening in the webapp project to facilitate frontend development and extension?

Thanks! Also thanks for all the recent development on this project. It's been very helpful.

Publish documentation for different versions

By now http://camunda.github.io/camunda-bpm-spring-boot-starter/ is published with the latest snapshot version. So the docus for a release are lost.

It would be much better to have the docs for every release and the latest snapshot like:

http://camunda.github.io/camunda-bpm-spring-boot-starter/snapshot/
http://camunda.github.io/camunda-bpm-spring-boot-starter/1.0.0/
http://camunda.github.io/camunda-bpm-spring-boot-starter/1.1.0/
http://camunda.github.io/camunda-bpm-spring-boot-starter/current -> 1.1.0/

http://camunda.github.io/camunda-bpm-spring-boot-starter/ should contain a table of content like link collection for the different versions.

For an example take a look at http://projects.spring.io/spring-boot/

support 7.4 services - implement ProcessEngineServices

I noticed that configuration for newer service api like DecisionService and ExternalTaskService was missing.
When we implement ProcessEngineServices in CamundaBpmAutoConfiguration, we will notice this on compile time in the future.

No qualifying bean of type [org.camunda.bpm.spring.boot.starter.CamundaBpmProperties]

We are creating SpringBoot gradle project with camunda-bpm dependencies in it. However when we run the Application.java - it throws following exception.

org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [org.camunda.bpm.spring.boot.starter.CamundaBpmProperties] is defined at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:371) ~[spring-beans-4.1.7.RELEASE.jar:4.1.7.RELEASE] at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:331) ~[spring-beans-4.1.7.RELEASE.jar:4.1.7.RELEASE] at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:968) ~[spring-context-4.1.7.RELEASE.jar:4.1.7.RELEASE] at org.camunda.bpm.spring.boot.starter.runlistener.AbstractFinishedWithNoExceptionRunListener.getBean(AbstractFinishedWithNoExceptionRunListener.java:80) ~[camunda-bpm-spring-boot-starter-1.0.0.jar:1.0.0] at org.camunda.bpm.spring.boot.starter.runlistener.AbstractFinishedWithNoExceptionRunListener.finished(AbstractFinishedWithNoExceptionRunListener.java:42) ~[camunda-bpm-spring-boot-starter-1.0.0.jar:1.0.0] at org.springframework.boot.SpringApplication.run(SpringApplication.java:323) [spring-boot-1.2.5.RELEASE.jar:1.2.5.RELEASE] at org.springframework.boot.builder.SpringApplicationBuilder.run(SpringApplicationBuilder.java:139) [spring-boot-1.2.5.RELEASE.jar:1.2.5.RELEASE] at org.springframework.cloud.bootstrap.BootstrapApplicationListener.bootstrapServiceContext(BootstrapApplicationListener.java:126) [spring-cloud-context-1.0.2.RELEASE.jar:1.0.2.RELEASE] at org.springframework.cloud.bootstrap.BootstrapApplicationListener.onApplicationEvent(BootstrapApplicationListener.java:75) [spring-cloud-context-1.0.2.RELEASE.jar:1.0.2.RELEASE] at org.springframework.cloud.bootstrap.BootstrapApplicationListener.onApplicationEvent(BootstrapApplicationListener.java:55) [spring-cloud-context-1.0.2.RELEASE.jar:1.0.2.RELEASE] at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:151) [spring-context-4.1.7.RELEASE.jar:4.1.7.RELEASE] at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:128) [spring-context-4.1.7.RELEASE.jar:4.1.7.RELEASE] at org.springframework.boot.context.event.EventPublishingRunListener.publishEvent(EventPublishingRunListener.java:100) [spring-boot-1.2.5.RELEASE.jar:1.2.5.RELEASE] at org.springframework.boot.context.event.EventPublishingRunListener.environmentPrepared(EventPublishingRunListener.java:59) [spring-boot-1.2.5.RELEASE.jar:1.2.5.RELEASE] at org.springframework.boot.SpringApplication.run(SpringApplication.java:285) [spring-boot-1.2.5.RELEASE.jar:1.2.5.RELEASE] at com.emc.gs.aaa.logic.service.Application.main(Application.java:53) [bin/:na]

The dependencies included in build.gradle is -
compile group: 'org.camunda.bpm.extension', name: 'camunda-bpm-spring-boot-starter', version: '1.1.0'
compile group: 'org.camunda.bpm.webapp', name: 'camunda-webapp-webjar', version: '7.4.0'

add banner

we should add a nice camunda ascii art banner.

Nice (but not required) if it would feature:

• spring boot version
• camunda version
• camunda starter version

Lifecycle events: ProcessApplicationStarted and ProcessApplicationEnded

Right now, we are relying on ApplicationListener finishedWithoutError and get Lifecycle interference with CommandLineRunner, ApplicationContextAware, ContextRefreshEvent, ...

I think it is a good idea to introduce custom events for camunda start/stop and encourage users to rely on these events only. Few notes: https://dzone.com/articles/better-application-events

switch to jdk 1.6

After some discussion we agreed to keep this on the camunda default 1.6 for now, which means we must edit the maven and project settings and check if anything beyond 1.6 was used so far.

since we have to leave the camunda default jdk 1.6 any way due to spring boot, wouldn't it be a good idea to walk the whole mile and just get on with 1.8?
I would believe that whoever works with spring boot is not bound to a close-to-outdated jdk level and we would gain all the cool features (lamdas, functional interfaces, suppliers, ...).

refactor package structure

we should use org.camunda.bpm as root package for all classes

jenkins failing after spring boot 1.3.3 upgrade

local build passes, but jenkins fails

https://app.camunda.com/jenkins/job/community-extension-camunda-spring-boot-starter/63/

since this only upgraded from 1.3.1 to 1.3.3 I cannot imagine why.

apply code formatting rules

Add http://editorconfig.org/ taken from: https://github.com/camunda/camunda-bpm-webapp/tree/master/webapp and adjust to java. Also check https://github.com/camunda/camunda-bpm-platform/blob/master/settings/eclipse/formatter.xml

Basically: text-intent 2 spaces instead of tabs.

apply camunda developer guidelines

In the past, we agreed on some rules when it comes to contributions. see http://camunda.org/contribute/

Rules for Java-based Projects

Java-based projects must use Apache Maven as build system. The groupId must start with
org.camunda.bpm.extension. The artifactId must start with camunda-bpm-*. camunda will supply a
maven pom template with sensible default values.

So the question is: do we drop these rules? Otherwise we should rename the repo and project root.

Create documentation infrastructure

In order to write good documentation I propose to use a combination of Asciidoc + Maven + GitHub pages to publish the docs for the users.
I would take care of the infrastructure for it.

Cannot use embedded forms on the app

Hello,

I've been working on an application using the webapp starter, and have been trying to get an embedded form to work. My project structure is very similar to the one found in examples/camunda-spring-boot-starter-example-webapp. I tried creating a folder src/main/webapp/forms with a file greetingForm.html , and modifying sample.bpmn so that the user task "do something" has form key app:embedded:forms/greetingForm.html, but I get a CORS error displayed when trying to view the form in the Tasklist.

We experienced a similar problem with a non-spring-boot Camunda project, and the issue went away when we used an META-INF/process.xml without any configuration, like:

<?xml version="1.0" encoding="UTF-8" ?>
<process-application
    xmlns="http://www.camunda.org/schema/1.0/ProcessApplication"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <process-archive>
    <process-engine>default</process-engine>
    <properties>
    </properties>
  </process-archive>
</process-application>

but the same approach doesn't seem to work here. The problem seems to involve the contextPath being null in the response below, which is obtained by tasklist app when using the API endpoint /api/engine/engine/default/task/1408

{"key":"embedded:app:forms/greetingForm.html","contextPath":null}

Can embedded forms work with the spring boot webapp starter? Is this a bug, pending feature, or something I'm missing? Thanks!

Provide links to external examples in README

Hi @jangalinski , @osteinhauer,

Do you think it would be good to merge @osteinhauer 's camunda-spring-boot-starter-examples with the currently existing ones and do some improvements on them?

write documentation

Write documentation in asciidoc. See index.adoc.

switch to camunda version 7.4.0

the starter should use the actual version 7.4.0

introduce history level "auto"

right now, when I configure multiple spring-boot nodes to run against the same camunda db, I have to manually keep the history level in sync, otherwise starting the node will fail (history level mismatch).

Since I might not want to think about it when adding new nodes, I suggest introducing a new history level "auto". It should behave as follows:

• if the configuration is set to "auto", try to determine the configured level of the database
• if found, use this level
• if not found, fall back to default (audit)

Embed Camunda WebApp

https://github.com/Zapata/camunda-spring-boot-embedded is embedding the camunda-webapp as a web-jar. Maybe we can do the same? WDYT?

Cannot set databaseSchemaUpdate to create-drop

In DefaultDatasourceConfiguration line 34:

configuration.setDatabaseSchemaUpdate(Boolean.toString(camundaBpmProperties.getDatabase().isSchemaUpdate()));

should rather read:

configuration.setDatabaseSchemaUpdate(camundaBpmProperties.getDatabase().isSchemaUpdate());

and so if you specify create-drop, the application fails to start up

Release 1.1.0

Hi @jangalinski, @osteinhauer,

What would you like to integrate into the 1.1.0 Release? I want to cut it and start working on the remaining issues.

Cheers,
Christian

allow deployment aware job executors

simple example does not finish because job-executor is not active

The simple application example runs into an endless loop while waiting for the processinstance to be ended because the final service task is async and there seems to be a problem with the job executor activation (though the default value is "true").

We should have a working example and a test that proves it works

add camunda 7.4 features

autoconfigure new 7.4 features (DMN, ...)

cannot create filter with webapp starter

I have the starter up and runing. I cannot see user tasks for the given sample process because no tasklist filters are active and I cannot create new ones. Anyone has the same problem?

project structure - separate extension and example

With the current setup, examples and implementation share some dependencies and dependencyManagement. This might get confusiing when you try to use the example-app as a template for your own project since it is not clear which dependencies you will need. Also there where mismatches between runtime behavior of ITests and SE when additional dependencies in Test scope triggered some "spring magic".

Suggested fix:
See https://github.com/camunda/camunda-bpm-dropwizard:

on top level the pom.xml will just reference two modules:

• extension - the actual production code
• examples - the example projects

It is ok to define some properties like camunda.version and encoding on this level, but no dependency management and so on.

The extension module will hold the starter projects. These may share common dependencies in the extension/pom.xml

The examples should use a plain spring-boot setup without any camunda-specific parent pom, so they have a clean classpath and only get what is defined in their poms. Examples should not share common dependencies (s.o.) so they can be used as a template for projects.