Versioning process definitions issue

Hi, guys!
Need your help

We use Camunda version 7.11, WildFly 16, shared engine
The task is to implement versioning of process definitions
The target is to have different versions of the same process (different .war archives) deployed on server application at the same time (like process_v1.war, process_v2.war).
Old process instances must be finished over old schema, models and java delegates.
New process instances must be created by new version of process definition (latest .war)

In order to create the instance of the latest process definition version we use version tag

RepositoryService repositoryService = processEngine.getRepositoryService();
String definitionId = repositoryService.createProcessDefinitionQuery()
				.processDefinitionKey(PROCESS_DEFINITION_KEY)
                .versionTag("v2")
				.latestVersion()
                .singleResult()
                .getId();

and than next we start the process instance

ProcessInstance processInstance = runtimeService.startProcessInstanceById(
                    definitionId 
            );

If the latest version (v2) of the process was deployed last on the application server, there are no problems, everything works as it should

But if we reload WildFly and the latest version of the process was not deployed last (last was deployed v1) we have some issues of class casting

The reason is that even when we try to create the instance of the v2 version of the process by process definition identifier, the control passes to the last deployed .war and then we get class cast errors

Will be very grateful for the help and tips in solving this issue

Hey @sergiikukhar,

maybe this thread helps you gain some insights into how sources are handled with regards to deployment versions.

Basically, only the sources of the newest deployment version are used in the server and therefore taken into account.

Hope that helps.

Best,
Tobias

1 Like

Be also aware of this one: https://jira.camunda.com/browse/CAM-11218

latestVersion() in combinatin with versionTag() works like you probably don’t expect it to.

1 Like

Thanks @tmetzke for link on this topic
But unfortunately this is not quite our case.

Thanks @fml2 thats was my next question))
I also used this documentation and this moment embarrassed me
I could not figure out how to use it correctly.