Spring-Boot + processes.xml: ENGINE-08043

Camunda 7 Topics Discussion & Questions
1

Hi Community,

when configuring a <resource/> in a <process-archive/> inside the processes.xml the process is being referenced twice. Running the project from IDE works but running the project from jar results in an error. I assume that the reason behind this is that the auto-deployment as well as the code running the processes.xml are trying to deploy the BPMN. Setting camunda.bpm.auto-deployment-enabled=false in application.properties has no effect, though.

Stacktrace

2020-10-14 14:02:39.315  INFO 20256 --- [           main] org.camunda.bpm.container                : ENGINE-08023 Deployment summary for process archive 'Demo: Deploying process error':

        processes/hello_world.bpmn
        BOOT-INF/classes/processes/hello_world.bpmn

2020-10-14 14:02:39.580 ERROR 20256 --- [           main] org.camunda.bpm.engine.context           : ENGINE-16004 Exception while closing command context: The deployment contains definitions with the same key 'Process_0un69zw' (id attribute), this is not allowed

org.camunda.bpm.engine.ProcessEngineException: The deployment contains definitions with the same key 'Process_0un69zw' (id attribute), this is not allowed

processes.xml

<process-application
        xmlns="http://www.camunda.org/schema/1.0/ProcessApplication"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <process-archive name="Demo: Deploying process error">
        <resource>processes/hello_world.bpmn</resource>
        <properties>
            <property name="isDeleteUponUndeploy">false</property>
            <property name="isScanForProcessDefinitions">true</property>
        </properties>
    </process-archive>
</process-application>

Github-Project for reproduction: GitHub - cit-gruenewald/camunda-sb-process-error: Demo project to showcase a potential bug in camunda-spring-boot-starter + processes.xml

Is this a bug or am I missing something rather critical? Any help appreciated.

Cheers,
Jan

2

As described here, since you’re using the @EnableProcessApplication annotation, you can simply use an empty processes.xml which will enable resource scanning. You’re essentially telling the application to deploy it twice with the current descriptor and the annotation.

Alternatively, in your processes.xml, set isScanForProcessDefinitions to false.

3

Hello Justin,

thanks for the reply. That’s what I was also suspecting.
So yes, you can work around this issue by omitting <resource/>-definitions from the processes.xml. But that shouldn’t be required.

My first point is (to quote from the link you posted):

This disables the SpringProcessEngineConfiguration auto-deploy feature and instead uses the required META-INF/processes.xml as an indicator for resource scanning.

I read this as: “@EnableProcessApplication disables auto-deployment of processes and only resources described by processes.xml will be deployed.”

And my second point is: camunda.bpm.auto-deployment-enabled=false should disable auto-deployment no matter what, but obviously it does not.
(well, maybe it does when not using @EnableProcessApplication but in this case auto-deployment should have been disabled anyways (see my first point))

So in my humble opinion, either the documentation is wrong or it’s a bug.
or
Coming back to my original post: I am missing or misunderstanding something.

(Test-Project referrs to 7.13.0; same behaviour can be observed on 7.14.0 though)

4

I was merely pointing out that an empty processes.xml was an option given you’re using @EnableProcessApplication.

And my second point is: camunda.bpm.auto-deployment-enabled=false should disable auto-deployment no matter what, but obviously it does not.

SpringProcessEngineConfiguration auto-deploy feature and the process definition scanning you can enable in processes.xml are two different mechanisms. You’re inherently disabling one with the annotation above and gaining an optional scan for process definitions option in processes.xml.

So when I pull down your code and set isScanForProcessDefinitions to false I get a successful startup with a single deployment of the bpmn. Similarly, I can get a successful startup if I keep isScanForProcessDefinitions set to true but remove the <resource> line (behavior as described here). This happens to correspond to what you get by default when processes.xml is just an empty file (as described here).

5

I think we’re talking about different things.
Please correct me if I’m wrong but I suppose you’re talking about potential solutions, while I’m talking about a potential bug.

So when I pull down your code and set isScanForProcessDefinitions to false I get a successful startup with a single deployment of the bpmn.

So far so good (this is what I would expect). But wouldn’t it also be correct to assume that when I set:
<property name="isScanForProcessDefinitions">false</property> in processes.xml
and
camunda.bpm.auto-deployment-enabled=false in application.properties
that no bpmn should be deployed? But actually the BPMN still gets deployed.

(and the documentation stating, that the use of @EnableProcessApplication would disable the auto-deployment makes it even worse)

So my question is: ‘How is that not a bug?’

6

Sorry, it wasn’t clear in your reply that you were able to get your example sorted :slight_smile: So, yes, let’s put that aside.

If you set isScanForProcessDefinitions to false (and auto-deployement-enabled inherently being false since we’re using @EnableProcessApplication), I would expect to only be turning off the automatic scan (not turning off deployment of resources completely). I would still expect the manually specified resource to still get deployed. That’s how I read the following, anyway:

  • isScanForProcessDefinitions : if this property is set to true, the classpath of the process application is automatically scanned for deployable resources. Deployable resources must end in .bpmn20.xml , .bpmn , .cmmn11.xml , .cmmn , .dmn11.xml or .dmn .
1 Like
7