Case Model Listeners not Found

Camunda 7 Topics Discussion & Questions
1

Hello,

I have a strange behaviour in my application concerning the CMMN Listeners, which I’m not sure if it’s a mistake on my part, or a bug in Camunda itself.

I have a rather large EJB/EAR application holding (among others) one Case Model and four Processes. Note: The Processes and the Case Model are being deployed automatically, when I deploy my application.

And here’s the thing: if the Case Model is not the last thing deployed (see picture), then the expression resolver will not be able to find the Listener beans. More specifically: I have a User Task connected to a Milestone, and the Milestone has a Case Execution Listener (Event Type: Occur, Listener Type: Delegate Expression, Delegate Expression: #{myListener}). When the user finishes the Task, the Listener is executed.

This works like a charm, if the Case Model is the last thing deployed. However, if a Process changes and gets redeployed, then the following exception gets thrown every time the Case Execution Listener should be executed:

Caused by: org.camunda.bpm.engine.ProcessEngineException: Unknown property used in expression: #{myListener}. Cause: Cannot resolve identifier ‘myListener’
at org.camunda.bpm.engine.impl.el.JuelExpression.getValue(JuelExpression.java:60)

Capture.PNG501×872 18.6 KB

To fix the error, I need to a) manually redeploy the Case Model and then b) redeploy the application. After that, it works again. …at least the instances of the newly deployed Case do. The older instances of the previous versions are still throwing the Exception.

Is this normal? I can’t imagine it being intended behaviour. And if it’s a mistake on my side (maybe the placement of the beans in the EAR) then how come it works if the Case Model is the last thing deployed? I would assume the EL Resolver can either find my beans or not, and not depend on the deployment order. Java Delegates in BPMN Processes also work regardless of the process deployment order.

I’ve managed to reproduce this behaviour consistently on different WildFly 10 + Camunda 7.6.x, 7.7.x, etc. Versions.

Sadly, I haven’t had the time to prepare a test application, but maybe one of the devs can say something about this.

Thanks & best regards,
Raul

2

Hellp Raul,

How does your processes.xml file look like? More specifically is it resumePreviousVersions activated? You can read more about it in the documentation.
Default behavior is that a previous deployment will be resolved based on the process definition keys. That means that resolver for the non-process (cmmn) won’t work. Which it would result into not finding the right class loaders.
If that’s the your case too please consider to change it to resumePreviousBy to deployment-name. (Keep in mind that you need to specify a deployment name during the deploy.)

Best regards,
Yana

3

Hello Yana,

Holy hell, that hit it spot on! :smiley: Adding the resumePreviousBy / deployment-name fixed it!

I’m still a bit fuzzy on the details though… According to the docs, previous deployments “will be resolved (by default) based on the process definition keys”. So… A Case Model will not be found this way because it’s not a process (doh!), and hence has no process definition key?

Furthermore, I understand that the second resolution method (by deployment name) makes sense perfectly well, when you want to resume instances of processes which are no longer present in the application, but my Case Model is still there…

Thank you very much!
Cheers, Raul

4

Hi Raul,

I am happy that you resolved the issue.

You are right on that, case model means no process definition key, so you need the deployment name.

resumePreviousBy is not relevant only to resuming of the instances but also to each redeployment.
When you redeploy your application this trigger the redeployment of the case model and that’s why you need resume previous by deployment name.

Best regards,
Yana

5