topic Difference between activiti:delegateExpression and activiti:class. Bug? in Alfresco Archive

Difference between activiti:delegateExpression and activiti:class. Bug?

richardmward — Thu, 20 Aug 2015 15:33:27 GMT

Hi,I have come across what I think may be a bug with the use of activiti:delegateExpression‍ as an alternative to activiti:class‍on both serviceTask‍'s and taskListener‍'s.When using activiti:class‍, one instance of a JavaDelegate‍ is created for each serviceTask‍ in a ProcessDefinition‍. When usin

Re: Difference between activiti:delegateExpression and activiti:class. Bug?

richardmward — Thu, 20 Aug 2015 22:52:24 GMT

I seem to be unable to edit the above post in which I have spotted a few errors - they are as follows:

"When using activiti:delegateExpression, one instance of a JavaDelegate, peroid." should read: "When using activiti:delegateExpression, one instance of a JavaDelegate is created, peroid."

The <code>JavaDelegate</code> code snippet should have <code>implements JavaDelegate</code>

"Now, if an instance of bpmn1 is started, when it reaches the serviceTask it will initialise all three of the Expression's in the JavaDelegate." should read: "Now, if an instance of bpmn1 is started, when it reaches the serviceTask it will initialise both of the Expression's in the JavaDelegate."

"For the time being, we are nullifying each of the Expression's at the end of the exectute method in each of our JavaDelegate's" - I am aware this may cause concurrency issues, and will be testing to prove that shortly. If anyone can suggest an alternative approach, it would be much appreciated!

Re: Difference between activiti:delegateExpression and activiti:class. Bug?

richardmward — Fri, 21 Aug 2015 09:25:56 GMT

Current resolution

We have removed out nullifiying code in order to not cause concurrency issues and instead have used <code>@Scope(BeanDefinition.SCOPE_PROTOTYPE)</code> on the beans used as <code>JavaDelegate</code>'s. This allows a new bean to be created each time it is accessed - i.e. a new bean will be created for each and every instance of a <code>serviceTask</code>. Whilst this is slightly inefficient, we don't anticipate issues as looking through the Activiti code we see:

in <code>ServiceTaskDelegateExpressionActivityBehavior.execute(ActivitiExecution)</code>
<java>
// Note: we can't cache the result of the expression, because the
// execution can change: eg.
// delegateExpression='${mySpringBeanFactory.randomSpringBean()}'
Object delegate = expression.getValue(execution);
</java>

Following the references to <code>delegate</code> from this point onwards, shows it being used in the following line (when the <code>delegate</code> is an instance of <code>JavaDelegate</code>):
<java>
Context.getProcessEngineConfiguration().getDelegateInterceptor().handleInvocation(new JavaDelegateInvocation((JavaDelegate) delegate, execution));
</java>

And checking <code>handleInvocation</code> I can see that the invocations are not held onto, so Activiti will release the delegates after they have executed, and then we can leave it to the garbage collector to clear the objects up.