Hot deployment

[bhj2]

I am using the activiti engine with spring.
I would like to do hot deployment for processes which use java classes & beans. The problem is about the deployment of java classes. Until now I put them in the classpath. Is it possible to do it without having to redeploy my web application?

I found that in the guide, but this is only possible if we user REST services.

Java classes

All custom classes that are used in your process (eg. JavaDelegates used in servicetaks or event-listeners, TaskListeners, …) should be present on the engine's classpath when an instance of the process is started.

But during deployment of a business archive, those classes don't have to be present on the classpath. This means that you're delegation classes don't have to be on the classpath when deploying a new business archive with ant.

When you are using the demo setup and you want to add your custom classes, you should add a jar containing your classes to the activiti-rest webapp lib. Don't forget to include the dependencies of your custom classes (if any) as wel. This is the same location where the activiti-engine jar is located. You can find this folder inside your distro at ${activiti.home}/apps/apache-tomcat-6.0.29/webapps/activiti-rest/lib/

Is there another solution?

Best regards

[frederikherema1]

Currently, there is nothing in activiti that allows deploying the JavaDelegates (and listeners etc.) alongside with your process, so they are reloaded when process is deployed, you're on your own here.

You could maybe take a look at JRebel, the have production-use stuff as well…

[bhj2]

Is that correct that hot deployment works but only using the rest app? The new version of the explorer doesn't use REST is that right? So it wont work… ?

Is there already a solution using OSGi? What is the project activiti-osgi used for?

If I put my application in a bundle and create new bundles for the new javadelegate classes I need, will the engine be able to find my JavaDelegate classes?


Sorry for all those questions and thank you for your very helpful answers!!

[frederikherema1]

With the new explorer, hot deployment of processes is possible, no problem.
Not only rest allows deploying, all calls to API deploy work (originating from rest or not).
I'm not very familiar with the activiti-osgi bundle, but I remember Guillaime Nodet (FuseSource) doing a hell of a job to get that right, so I'm quite confident activiti-osgi bundle is what you need.

[bhj2]

With the new explorer, hot deployment of processes is possible, no problem.
Not only rest allows deploying, all calls to API deploy work (originating from rest or not).
I'm not very familiar with the activiti-osgi bundle, but I remember Guillaime Nodet (FuseSource) doing a hell of a job to get that right, so I'm quite confident activiti-osgi bundle is what you need.

Yes, what we need now is hot deployment of JavaDelegate classes. Is there any doc to understand what is the purpose and what is done in activiti-osgi? I didn't find anything and there is no comment in the code.

[vikashkumarsing]

I am able to deploy the jars containing classes for actions and tasks using simple java trick. For tomcat container provide the custom implementation of WebappClassLoader which able to load the jars at runtime using addURL() method of URLClassLoader but this custom implementation varies for tomcat container version(different implementation for 7 and 8). There is another way of providing custom class loader to process engine itself which can able to add urls of jars at runtime.

[vasile_dirla]

Hi,
yes, there are multiple ways to archive this "hot deploy" functionality:
1. as you already said, a custom class loader can do that
2. configure the web application context:
<code>
<Context … reloadable="true">
<WatchedResource>path/to/watched/resource</WatchedResource>
<WatchedResource>another/path/to/another/resource</WatchedResource>
</Context>
</code>

but don't forget to be pay attention when "hot-deploying" classes into a class loader.
When the redeployed classes are already loaded, the reload process can fail and then the only recovery solution is to restart your tomcat.
this happens because there are information in PermGen which cannot be removed since are referenced by various instances in your JVM.

This error is:
"PermGen out of memory"
this could be fixed by adding these arguments: <code>-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled</code>