Exposing Process Engine to Web Resources

Hi,

I’m using the a Spring Managed Process Engine Configuration (process engine is defined inside of a applicationContext.xml file). The Process Engine seems to load fine. However, via the engine-rest app, it can’t seem to find it:

org.camunda.bpm.engine.rest.exception.RestExceptionHandler.toResponse org.camunda.bpm.engine.rest.exception.InvalidRequestException: Process engine with name default does not exist

In my main log, I see that I have two process engines (expected in my case):

...
21:42:47 org.camunda.bpm.engine.cfg( 128) - ENGINE-12003 Plugin 
'ProcessApplicationEventListenerPlugin' activated on process engine 'default'
21:42:50     org.camunda.bpm.engine( 128) - ENGINE-00001 Process Engine default created.
...
...
21:43:01 org.camunda.bpm.engine.cfg( 128) - ENGINE-12003 Plugin 
'ProcessApplicationEventListenerPlugin' activated on process engine 'defaultc'
21:43:04     org.camunda.bpm.engine( 128) - ENGINE-00001 Process Engine defaultc created.
...
... 
21:43:28 org.camunda.bpm.engine.rest.exception.RestExceptionHandler.toResponse 
  org.camunda.bpm.engine.rest.exception.InvalidRequestException: Process engine with name default 
  does not exist
...

I have verified my engine-rest app is deployed.
I have also tried reversing the order and naming of the two process engines without luck as well. It just seems like the process engines are setup internally, but the camunda app doesn’t know about them…

The url I’m trying to access is something like:
https://host:38443:/camunda/api/admin/auth/user/default/login/cockpit

Thanks,
Galen

@Galen_Hollins From the log I can see you are created two process engines default and defaultc. Can you provide the process engine configuration?

Hi @aravindhrs ,

Actually, I did some more experimenting, and this behavior is seen when I copy some camunda jar files into my webapp (WEBINF/lib) directory. I think something extra in there was causing this. I say that, because when I removed those extra jars, I no longer see the behavior I described above.

So in any case it looks to be resolved now, and was probably related to some conflict on the classpath/classloader.

Thanks,
Galen