topic Re: Dynamic JavaDelegates in Alfresco Archive

Dynamic JavaDelegates

mmaker1234 — Wed, 06 Nov 2013 14:09:11 GMT

Hello Activiti developers, community,We have a requirement to provide the ability to load new and update workflow process definitions and their corresponding JavaDelegates during the application run. And before you to send me to the forum search let me note that I already read the followingeployin

Re: Dynamic JavaDelegates

felipe1 — Wed, 06 Nov 2013 14:15:49 GMT

Monique, have you looked the OSGI approach? It's described in chapter 9 from the book Activiti in Action. I do not use it, personally, but it seems to be a good fit in your scenario.

I'm interested in this subject, so I'll keep an eye in this post. Hopefully someone with more experience will post a more appropriate answer.

Re: Dynamic JavaDelegates

trademak — Wed, 06 Nov 2013 14:53:04 GMT

May I ask which application server you are using?
We are thinking about providing more support around this for JBoss 7.
Right now the best approach would be to use EJB's for you service logic. Then you can invoke that EJB from the Java delegate. If you keep the interface flexible you should be able to replace the EJB component with a new version.

Best regards,

Re: Dynamic JavaDelegates

mmaker1234 — Thu, 07 Nov 2013 09:07:31 GMT

Hello Tijs,

About the beginning of my original post I already stated that: "Our environment is the following:
Enterprise application (EAR) running in WebLogic application server;"

To be honest I do not catch with your idea with the "adapter" JavaDelegate. My concern is that I can not make the JavaDelegate flexible enough: what would happen if I need to add another field (delegate parameter) in the process definition? Then I would need (again) to refresh the JavaDelegate class in run time. Or there is other way to get the fields from within the JavaDelegate in order to provide them to the EJB? Nevertheless I suppose that the call to the JavaDelegate will fail with missing setter/field when the new version of the process definition is instantiated (and the JavaDelegate "missed/failed" to update). Do I miss something in the JavaDelegate invocation mechanism?

Another option could be to change the process definition to parametrize the JavaDelegate using variables instead of fields. Then to make the delegate to "know" the EJB to call and flexible enough to look-up a setter for each process instance variable (while not failing on missing setters). This approach means:

To mandate the use of statefull EJBs, which are much difficult to maintain;
The whole mechanism of JavaDelegate parameters definition becomes hidden
as one need to read all the process to reveal what value a variable might have in a certain activity;
the EJB setters must be carefully reviewed on each process definition change
and error prone - at least there will be no error if some parameter (variable) is missing a setter (due to the flexibility described above)

Cheers,
Monique

Re: Dynamic JavaDelegates

mmaker1234 — Thu, 07 Nov 2013 12:39:46 GMT

OK, we have something that looks like a solution.

It seems that adding the pgadecki's change to our "Forced <code>ClassDelegate.execute(ActivityExecution)</code> and <code>ClassDelegate.signal(ActivityExecution)</code> to always call <code>getActivityBehaviorInstance(execution)</code>" we got something that satisfies our needs.

We tested each change separately and any of them alone does not work for us.

Now the question is: Are these changes critical to the work of the Activiti Engine? Subquestions:

What is the reason the variable <code>activityBehaviorInstance</code> to be global in <code>ClassDelegate</class>? It is shared only between <code>execute</code> and <code>signal</code> methods. AFAIR there is no activity to be simultaneously executable and signallable but the implementation provides some kind of a hidden cache. Nevertheless, once the code is written in this manner probably I'm missing something …;
Why it is so critical to use <code>clazz = Class.forName(className, true, classLoader)</code> in <code>ReflectUtilloadClass(String)</code> in the case a (custom) ClassLoader is available?

Re: Dynamic JavaDelegates

trademak — Wed, 13 Nov 2013 11:15:34 GMT

Hi,

Why not implement the routing logic in a stateless EJB as well? So from the java delegate class you just pass along execution info + the process variables to a fixed EJB. Then in this EJB you invoke the EJB you need. This makes the process definition independent from the EJB logic. Yes this means you will have to work with variables instead of field declarations.

About your changes. The activityBehaviorInstance is global because it's instantiated only once and reused when the same service task is executed again. This is for performance reasons.
In don't understand your comment about ReflectUtil. Class.forName(className, true, classLoader) uses the custom classloader to load the class, so why would you want to change that?

Best regards,

Re: Dynamic JavaDelegates

mmaker1234 — Wed, 13 Nov 2013 13:19:20 GMT

Hello Tijs,

Thank you for your answer.

Let me start from the Class.forName() behavior. Our investigation (debug, actually, including the Java runtime) revealed that the Class.forName(String, boolean, ClassLoader) calls the private native method Class.forName0(String, boolean, ClassLoader). On the first call to it, forName0() really reaches the (our custom) ClassLoader findClass() method. On the subsequent calls for the same class name and class loader, though, forName0() directly returns, most probably using some internal caches, the class instance thus never reaching again the findClass() in the class loader. At least this is the behavior of JRE 1.7.40 on Windows. I can not claim how JRE behaves on Linux.

As an opposite, classLoader.loadClass(String) always reaches the ClassLoader findClass(). Obviously that class caching mechanism is not implemented/activated in loadClass() call sequence or internal implementation.

Now lets get back to the JavaDelegates. I personally think that your solution:
1. Is overcomplicated for our case. Nevertheless it might be just the right solution for other Activiti Engine users;
2. Trades the process definition clarity for speed.

As our usage of the Activiti Engine (currently) does not require high throughput we will sacrifice the engine performance for flexibility and process definition clarity by going with the above solution.

Paweł Gadecki's approach ( http://forums.activiti.org/comment/8802#comment-8802 ) is also tempting but I'm afraid it requires much more changes.

Regards,
Monique

Re: Dynamic JavaDelegates

trademak — Wed, 13 Nov 2013 21:17:16 GMT

Hi Monique,

And that's why we use the Class.forName code in the ReflectUtil class, because by default we want to cache the class instance for reasons I previously explained. But your use case is valid of course. So let's think about a possible solution that could be implemented in the Activiti Engine module.

To start we need to get clear requirements about what's needed. Let me give a first try at that and you can change it to your needs:

The Service task class instance should be recreated at every execution of the service task activity. Right now the instance is cached and this can only be done by changing the Activiti Engine code.

We could add an activiti:singleton="false" attribute. When this is added no class caching is done and a new instance of the Class is created at every execution. Would that fit your requirements?

Best regards,

Re: Dynamic JavaDelegates

mmaker1234 — Thu, 14 Nov 2013 12:58:45 GMT

Hello Tijs,

Yes, our current vision is that we need "The Service task class instance should be recreated at every execution of the service task activity" and I think that an attribute will work well for us.

Thank you for your receptivity! 🙂
Monique

P.S. Once we started a discussion and you opened to changes in the Activiti Engine regarding the JavaDelegate dynamics, what about Paweł Gadecki's idea of providing a separate class loader for each deployment? Or it is too risky for the Engine stability? Is this approach much different from the use case with a custom class loader (provided in the engine configuration) in the perspective of the Engine security and stability?

Let me elaborate a little:

Our approach allows separate deployment of the JavaDelegates and the process definition:
The JavaDelegate distribution is separate from the process definition distribution;
The JavaDelegate deployment is handled by the environment (usually an application server) and not the Activiti Engine;
A JavaDelegate replacement immediately affects the running instances of all versions of all process definitions
Any change in a JavaDelegate must be made with the thought of compatibility with older versions of the deployed process definition. (We are aware of this and are ready to take care for the backwards compatibility but others might not notice this effect)
Requires the new JavaDelegate version to be deployed on each node of a cluster configuration.

Paweł's approach ties the JavaDelegates implementation to the process definition version, thus encapsulating all process definition supplements (JavaDelegates) in a dedicated execution environment
The JavaDelegate is bundled in the distribution package of the process definition;
The JavaDelegate distribution is handled by the Activiti Engine database. An access to it is provided via the Engine deployment management API;
A change in a JavaDelegate affects exactly one version of the process definition;
To apply the changes in a JavaDelegate the process definition have to be re-deployed;
The changes will take effect only with the new instances of the process definition;
Removal/bypassing of the Activiti Engine caching mechanism is not required;
Provides better scalability (in a cluster) due to the common deployments repository

Whether the above features of the both approaches are pros or cons each Activiti Engine user should decide for himself.

Re: Dynamic JavaDelegates

pmsevestre — Fri, 15 Nov 2013 01:37:41 GMT

IMO, you should not even try to do this with Java. You can achieve what you want with Groovy delegates, which is almost exactly what I'm doing in my Ativiti-based app.

1. Use the process parsing hooks (http://www.activiti.org/userguide/index.html#advanced_parseHandlers) to dinamically add delegates to a wrapper that will load user scripts on demand. You can use a convention-based approach or something more elaborated (eg: a DB lookup)
ca
2. When a process instance reaches a given activity that, it will execute your (fixed) delegate, which in turn will:
2.1. lookup ou create a GroovyClassLoader instance that load scripts from your script repository (eg: filesystem ou a JCR based content - the former can give you script versioning,for instance).
2.2. Use this classloader to instantiate the actual delegate
2.3. execute the delegate
2.4. handle exceptions, etc

Groovy scripts can do anything Java can, so there is no loss of functionality there.

If the user changes any script, GroovyClassLoader will pick the changes and apply them on the next invocation.

Re: Dynamic JavaDelegates

mmaker1234 — Fri, 15 Nov 2013 12:09:13 GMT

Hello,

What you are loosing in your approach is at least the possibility to debug especially when you need a complicated logic. That is why we prefer to stay with the Java classes.

In our case we need to load Domain Objects (EJBs) from the DB, to evaluate their state (with somewhat complex logic, including calls to the application's business logic) and then store back some changes using our persistence mechanism. All this should happen under the transaction management of the application server. I'm not quite sure the Groovy script will allow us all of this.

Re: Dynamic JavaDelegates

pmsevestre — Fri, 15 Nov 2013 13:47:41 GMT

You can set breakpoints in Groovy scripts and single-step them, inspect variables and so forth, so there is no loss in my serviceability in my approach. This is what I do everyday in my environment. The IDE (Eclipse) connects to the application server (regular Tomcat, in my case) and I'm able to do all debugging I want. Usually, those scripts perform some business logic that ties state from a given process instance with backend services (webservices, EJB calls).

Please note that this approach works with groovy classes instantiated using the GroovyClassLoader approach I've described.I tried to do this with other JSR-223 script engines but their debug support is poor. This is also the reason that made me ruled out the use of "script tasks" in my processes.

Re: Dynamic JavaDelegates

rolf — Wed, 19 Feb 2014 11:20:09 GMT

Hello!

Pawel's approach is exactly what I need!
I want to package the process definition and delegates in a jar-file and deploy it.
Each version of the process definition sould have its own version of delegates.

Is there any sample code?
How do I get the Execution Context in the class loader?

Thanks for your help!

Re: Dynamic JavaDelegates

dimitrihautot — Thu, 20 Feb 2014 14:28:28 GMT

Hello,

I came up with a different solution.
It might not be a perfect use case for other users, but I thought I could share it anyway. It could open new possibilities. 🙂

My web application doesn't have the Activiti engine embedded. The engine is deployed on a slightly modified of the default activiti-rest-webapp, provided by Activiti.

The web application talks to the Engine through REST calls, thanks to the now standardized REST API.

On the BPMN definition, the only JavaDelegate defined is a class that invoke custom URIs, providing its current Execution state, variables, tasks, … as a set of JSON objects.

These custom URIs (=callback URIs) are "hardcoded" in the XML. They usually point back to the web application, which is then allowed to notify clients of the BPM progress.

The callback URIs can also query the engine using the REST API, but are <strong>strongly</strong> discouraged to perform any update with the REST API.
The callback URIs may also update process variables and ship them in the response sent back to the process engine.

Finally, the JavaDelegate inspect the response and persist updated variables in the database, all within the same transaction.

With this approach, the only classes I need to provide to the engine are rather generic. All the decision logic is delegated to another webapp/JVM.

Implementation note: I initially based these URI invocations on Restlet, but it seemed to randomly close response streams. Activiti REST webapp is compiled against Restlet 2.0.x branch, so I couldn't upgrade to the latest 2.1.y branch.
In the end, I replaced the invocation logic by using java.net.URL. Rather basic, but enough for a simple POST request.