We had the following code implement eventListener to do some logging. This captures all the events of all the artifacts in a workflow.
@ProcessApplication(“TestApp”)
public class PrintCounterApplication extends ServletProcessApplication{
public ExecutionListener getExecutionListener() {
System.out.println("in listener");
return new ActivityLoggingExecutionListener();
}
}
public class ActivityLoggingExecutionListener implements ExecutionListener {
public void notify(DelegateExecution execution) throws Exception {
System.out.println("IN : " + execution.getCurrentActivityName());
}
}
Later suggestion was for to have this in POM so that we deploy multiple version of the application and remove the @ProcessApplication needs to be removed (with @ ProcessApplication annotation we get application already registered error message even when we try to deploy a different version of the war than that is deployed).
org.camunda.bpm.javaee
camunda-ejb-client
With @ProcessApplication commented the listener doesn’t get triggered. I understand that we can add a listener class to the activity to achieve the same. Other than this, any suggestion to handle this scenario?
I recommend you read up on EjbProcessApplication. In particular, when you provide a custom subclass of EjbProcessApplication, you should not invlude camunda-ejb-client in your deployment.
we didnt had camunda-ejb-client in to start with. however, when we want to deploy a newer version (with an older version already running on the server) we get an error saying Service is alteady registered in the logs.
to solve the deployment issue, the sugggestion was to remove p@ProcessApplication annotation and add the camunda-ejb-client setting. this seems to break the event listener that we had in place.
You can’t have two process applications with the same name running at the same time. This is regardless whether they are part of the same deployment archive or whether they are part of two different archives. That means:
Make sure your deployment archive contains exactly one process application class (either the one contained in camunda-ejb-client or a custom one)
When deploying a new version, first undeploy the old version, then deploy the new version. Not the other way round. Or replace the deployed application in your server, it should then do these steps in this order
If you are already adhering to these tips, I suggest you post which application server you use and an extract of the server log files from the time of redeployment.
when i make the change to add the camunda-ejb-client i loose the event logging capability that we used. my question is if there is a way to get the similar behaviour with camunda-ejb-client setting.