Hi, we are multiple developers working on a shared DB, and we keep having this error, when differents branches of the projects with older/newer definitions than the ones actually deployed in the db are started :
2022-04-07 09:50:09,870 ERROR [RMI TCP Connection(3)-127.0.0.1][org.springframework.web.context.ContextLoader] Context initialization failed
org.springframework.context.ApplicationContextException: Failed to start bean ‘processEngineConfiguration’; nested exception is org.flowable.common.engine.api.FlowableException: deployment ‘1907501’ didn’t put process definition in the cache
the workaround is to delete the deployment mentionned in the exception, but as soon as someone else start another version, the problem is comming back
Is there a way to segregate the database schemas or instances for Flowable by branch? The idea being that say branch one has its own set of Flowable tables, branch two another set and so on. Mixing deployments in the same database with the same process definition names but differences in the definitions is going to cause problems. You could also consider running each Flowable database locally for each deployment but share the part of the database that relates your business data.
That’s a really odd - this exception should only happen if the definition is put cache and the line afterwards isn’t there anymore. Are you perhaps using a non-default limited cache for the definitions?
Using branch-specific settings on that branch would be the only way. Flowable doesn’t need one database schema, you can easily a schema per engine instance.
when the resource is in a jar, we get a IO exception to ‘resourceName = resource.getFile().getAbsolutePath();’
and then the resource name fall back to be just the filename.
while deploying within a unit test, we get the absolute path which contain the full path.
so flowable will try to deploy again the definition, which is the same, ending with the error
so I got around the pb by creating a custom DeploymentStrategy (SpringProcessEngineConfiguration.deploymentStrategies) that override determineResourceName and then always return resource.getFilename()
I’m not yet following how this would lead to the error: when the IOException happens, it is catched and then indeed a fallback name is used. But I don’t see yet how that could lead to the exception shown above.
Do you have a way to reproduce this so we can check it?