camunda / camunda-bpm-spring-boot-starter Goto Github PK
View Code? Open in Web Editor NEWCamunda BPM bootified!
License: Apache License 2.0
Camunda BPM bootified!
License: Apache License 2.0
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
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/
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?
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
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:
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.
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!
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 ...
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?
And just import the Spring-Boot parent pom in the dependencyManagement section.
This allows releasing the project to Camunda Nexus and Maven central.
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.
autoconfigure new 7.4 features (DMN, ...)
https://github.com/Zapata/camunda-spring-boot-embedded is embedding the camunda-webapp as a web-jar. Maybe we can do the same? WDYT?
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, ...).
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:
For this to work, we must register the deployment (PA) and configure the job executor accordingly so the jobExecutorDeploymentAware flag is working correctly.
we should use org.camunda.bpm as root package for all classes
the starter should use the actual version 7.4.0
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
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'
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.
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?
we should add a nice camunda ascii art banner.
Nice (but not required) if it would feature:
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.
because the starter is for camunda-webapp it should match the name.
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?
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:
org.camunda.bpm.engine.impl.cfg.ProcessEngineConfigurationImpl.init()
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
we should have automated builds and snapshot repos
When you look at https://github.com/camunda/camunda-community-project-blueprint, a few things are missing in this extension (besides optional renaming #5).
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
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
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?
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.
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?
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.
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
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.
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
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
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.
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.
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.
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
A customer asked me if there are any plans to integrate this into http://start.spring.io/
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.
Write documentation in asciidoc. See index.adoc.
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.
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.