JavaDelegates not found after redeploying provided BPM

Hi,
I created a project which creates a war file based on https://github.com/camunda/camunda-bpm-examples/tree/master/deployment/servlet-pa.

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?

Best Regards
Alex

Hi Alex,

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.

Do you have additional questions?

Best regards,
Philipp

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?

Best Regards
Alex

Hi Alex,

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.

Does this answer your questions?

Best regards,
Philipp

Hi again,
thnx for the fast response. I hope my next question is not too “dumb” :slight_smile:

We are using a shared process engine and I wonder how I can get this done. Do you say, that I have to

  1. Register the redeployed bpm file everytime I deploy it into camunda and register the deployment-id to the provided process application?
  2. 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

Best Regards
Alex

Hi Alex,

it’s the first option. Whenever you redeploy a process then you have to register your process application for the new deployment.

But as I mentioned, there are easier ways to deal with updated processes.

Best regards,
Philipp

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)

Best Regards
Alex

Hi Alex,

regarding your message

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.

Best regards,
Philipp

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 :frowning:

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.

Perhaps I have to have a deeper look into EJBs (The Process Application class | docs.camunda.org)

Best Regards
Alex

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).

Best regards,
Philipp

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 :wink:

Best Regards
Alex

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).

1 Like