Container managed ProcessEngine not resolving JavaDelegate

Camunda 7 Topics Discussion & Questions
1

Hi,

I have troubles resolving Spring managed JavaDelegates from my shared ProcessEngine configured in a Tomcat container.

My spring web application declares a bean of type SpringServletProcessApplication. The application also injects the ProcessEngine with the BpmPlatform service

<bean name="processEngineService" class="org.camunda.bpm.BpmPlatform" factory-method="getProcessEngineService" /> ...
The ProcessEngine is derived from the ProcessEngineService then.

My web app is able to communicate with the ProcessEngine but when I start a ProcessInstance for a process which is referring to custom JavaDelegates, I get an error:

org.camunda.bpm.engine.ProcessEngineException: Unknown property used in expression: ${myCustomDelegate}. Cause: Cannot resolve identifier ‘myCustomDelegate’

I am not quite sure, how my ProcessApplication and its JavaDelegate are looked up by the container managed ProcessEngine.

Am I missing something in my setup?

Chris

2

Hi Chris,

Where is camunda-engine-spring located in your setup?

Cheers,
Thorben

3

Hi Thorben,

the camunda-engine-spring is packed in my webapp-war.
It is the only jar which is not located in the shared lib folder of my Tomcat. This is, because initially the ProcessEngine was created by the webapp itself.

4

Hi Chris,

The following method implements bean lookup in the context of an expression:

Basically, the process engine looks for an implementation of org.camunda.bpm.application.ProcessApplicationElResolver via Java’s ServiceLoader API using the classloader of your process application. camunda-engine-spring provides such an implementation, see SpringProcessApplicationElResolver. That is also why it is required to have camunda-engine-spring on the application’s classpath. So on first sight, everything looks ok. Perhaps you can debug if the process application EL resolver is invoked at all.

Cheers,
Thorben

5

Hi,

thank you for the hint. While debugging, the application did not stop at my breakpoint in the initProcessApplicationElResolver method.

What i did find out though, was that the method

org.camunda.bpm.application.AbstractProcessApplication.deploy()

is called.

What i also found out is, that

Context.getCurrentProcessApplication()

returns null, when called in

org.camunda.bpm.engine.impl.el.ProcessApplicationElResolverDelegate.getElResolverDelegate()

I am not sure, if this has something to do with the initial problem but it looks to me, that my ProcessApplication is not found although it has been deployed on Tomcat startup.

6

FYI: I am using Camunda 7.5.0

7

How do you deploy your processes?

8

Hi,

I managed to solve the problem today. Sorry, there was no time to post the solution earlier.

My processes were deployed over an embedded ProcessEngine. Then I had to switch to the container managed shared ProcessEngine. The database was reused so the processes were already deployed:

I did not specify a processes.xml file in my webapplication.

At the Tomcat startup Camunda mentioned in the console log that my ProcessApplication was deployed and there was no processes.xml found. I though that Camunda is fine with no processes.xml because there was no error.

Later I tried the setup with the processes.xml and the initProcessApplicationElResolver() method was then called indeed. Unfortunately my delegate bean is still not found.

applicationContext.containsBean(key)

in

org.camunda.bpm.engine.spring.ApplicationContextElResolver

returns false

UPDATE: The bean can be found now. I guess there was a clash because the applications default component-scan and explicitly declaring the delegate bean in the application context xml.

Another UPDATE:
The problem was, that I did define the <bean class="..." /> without ID. I supposed, Spring would take the classname automatically as ID like it does when declaring a bean only with the @Component annotation.

9

My problem is solved but there is still one question for me:

Is the processes.xml mandatory for process applications using a shared process engine?

10

Yes, it is required. It can be empty, though, see https://docs.camunda.org/manual/7.6/user-guide/process-applications/the-processes-xml-deployment-descriptor/#empty-processes-xml

11

Thanks for clearing that.

I tried that and got:

ENGINE-08025 Detected empty processes.xml file, using default values

Is there any reason why there is not the same behavior when no processes.xml was detected at all?
This is the INFO log output when no processes.xml is found:

ENGINE-08026 No processes.xml file found in process application ‘myProcessApplication’

12

I’m not sure. I think it is meant to be consistent with CDI, where only the presence of an (empty) beans.xml file enables CDI.

13

Thank you a lot for your help and clarification!

Chris

14

Hi thorben,

I am also facing same issue in the shared process engine.

Instead of loading SpringProcessApplicationElResolver , CompositeELResolver is getting loaded. camunda-engine-spring is located on the individual application’s lib path not on the global/tomcat lib and have created empty processes.xml as well.

Can you please help me on this?

Thanks.

15

Hi @thanigachalamp

There’s no need to post on a 4 year old thread, you’ve already posted the topic, wait for a reply before duplicating your question. Please read the FAQ for some tips on good forum etiquette.