If I deploy this war to Wildfly 10 everything works fine. I can use the defined JavaDelegate in the provided bpm file.
But if I redeploy the provided bpm as version 2 with another name I will get a NoClassFoundException for the JavaDelegate in my war file. Same happens if I only deploy the JavaDelegate without a provided bpm file.
I think its caused by the classloading of the war file. If the bpm is only used, its context is the war file. By redeploying it the context changes.
Is it correct that by redeploying the bpm the context changes and the JavaDelegate will be searched âsomewhereâ else?
If so, is it possible to expose the JavaDelegate while deploytime so its usable in all new created service tasks?
itâs related to class loading. A process application registers itself while deploying. After itâs registered, the process engine can find the classes which are used by the process in the process application. If you redeploy a single process then the process application isnât registered by default and the classes canât be found (note that the classes live in the scope of the process application and are separated from the process engine).
You can find more details in the user guide.
Hi Philipp,
thnx for your reply. I think I have only one question: Do you say that it is impossible to redeploy a provided bpm file with custom delegates? Or is it possible do register the delegate in the war file for this new single process somehow?
the short answer is that itâs possible. If you redeploy the whole process application (the WAR file with process application class + delegates + processes) then all works fine. Note that only the changed processes will be deployed again, the others stay in the same version.
If you use an embedded process engine then this is no problem because you donât have any classloading problem.
If you use a shared process engine (e.g. in the Wildfly distro) and only want to update one process without redeploying then you have to register the process application manually for the new deployment.
You can also avoid these problems if you use external tasks instead.
Hi again,
thnx for the fast response. I hope my next question is not too âdumbâ
We are using a shared process engine and I wonder how I can get this done. Do you say, that I have to
Register the redeployed bpm file everytime I deploy it into camunda and register the deployment-id to the provided process application?
Or do I have to register my process application one time after deployment, like this to get the delegate âpublicâ?
@ProcessApplication(âBPM Example applicationâ)
public class ExampleApplication extends ServletProcessApplication {
private final static Logger LOGGER = Logger.getLogger(ExampleApplication.class.getName());
@PostDeploy
public void postDeploy(ProcessEngine processEngine) {
LOGGER.info(âPost deploy for bpm example process application.â);
processEngine.getManagementService().registerProcessApplication(âtest-idâ, this.getReference());
}
}
The first one would make more sense, but I think it would be complicated to know which bpm belongs to which PA
Ok thnx for the help :),
I tried to get it done by using the External Task, but there I have some problems other problems.
The only working solution for me would be to add a TaskListener where I trigger the âfetchAndLookâ to get this task done, but the taskListener is also a JavaClass and therefore I will run into the same NoClassDefFound Exceptions.
I think I will check how I can register a new deployed process to the provided process application. (I wonder if this is possible through the REST Api)
No, you canât register a process application via Rest API.
Besides that, it sounds a bit odd that you call âfetchAndLockâ in a task listener. You should call it in the process application because the application wants to work on the task. Note that the process runs in the application server thread.
Besides that, it sounds a bit odd that you call âfetchAndLockâ in a task listener. You should call it in the process application because the application wants to work on the task. Note that the process runs in the application server thread.
Yes it sounds odd, but I did not find a better solution for the first try.
What I want to do is to get the PA informed if a external Task was triggered. But if I understand this correctly, I have to âaskâ explicitly, if there are some tasks which got this external Task topic name (according to External Tasks | docs.camunda.org). Asking could be happen through âpollingâ or registering to a proper listener. And the only listener I found was the TaskListener
If I am honest, I would like to use the JavaDelegates and get these (war file) provided delegates pushed in a âglobal contextâ to be able to use these delegates in all new or existing BPMs.
Thatâs correct. External tasks follow the poll principle (i.e. no push notification when a new external task is created).
However, the easiest way is to provide a WAR file which contains the processes and the business logic (i.e. Java Delegates). If you need to update the processes or business logic then you have to update the WAR and redeploy it.
If you want to update the processes independently then you have to register the process application manually and keep in mind that the process may be overridden when the WAR is redeployed (e.g. on application server restart).
You are right. BPM updates to a provided file would be lost after war redeployment. But I try to create and deploy a new BPM and using the delegates from provided war file.
Perhaps its not that practical to do this
Update to this (perhaps its interesting for someone):
To solve this not found issue after redeployment, we created an old school unmanaged ear file in Wildfly 10, where we put all our process applications into an lib folder. This way, we are able to share JavaDelegates in all of our BPM models (provided and redeployed one).
