topic Re: Next steps for the spring component integration in Alfresco Archive

Next steps for the spring component integration

tombaeyens — Mon, 28 Feb 2011 07:07:49 GMT

[27/02/11 12:47:23] Josh Long: ive officially got 70% of what i wanted to support in the component code for the Spring module working. i wondered if i might talk to you about the last 30% [27/02/11 12:54:39] Josh Long: at the moment, there is support for: 1) Activiti POJOs:class CustomerService {

Re: Next steps for the spring component integration

jbarrez — Mon, 28 Feb 2011 09:18:06 GMT

Awesome progress. Really powerful stuff, Josh!

Re: Next steps for the spring component integration

joshlong — Tue, 01 Mar 2011 02:47:10 GMT

Thanks guys. My intent wasn't to get priase, however. I want to get help implementing the last part in activiti core. Basically, i want to enable service tasks that dont have an activiti:delegate or anything, theyre empty:


<serviceTask id = "enroll-customer" />

I want to setup the ProcessEngine to then attempt to look up the correct handler (like a 'default' handler JavaDelegate o ReceiveTaskActivity ).

The idea is that the default ReceiveTaskActivity would then be pluggable. For Activiti-Spring module, you could have a dispatcher that invokes beans in the Spring context that have annotations that 'register' them to the state as handlers:

@ActivitiMapping( serviceTask = 'enroll-customer') 
public void handleEnrollCustomerTask() { }

@ActivitiMapping( serviceTask = 'enroll-customer') 
public void handleEnrollCustomerTask(  @ProcessVariable( "customerId") Long customerId ) { }

@ActivitiMapping( serviceTask = 'enroll-customer') 
public void handleEnrollCustomerTask(  @ProcessInstance ProcessInstance pi, 
                                                 @ProcessVariable( "customerId") Long customerId ) { }

etc.

These methods would be invoked automatically and enlisted to handle the service task and other things. T

This extension mechanism would of course be useful to anybody building on top of Activiti (Spring, CDI, … anybody!).

Right now, I already have basic support for explicitly defining a 'registry' that handles the mapping to those beans with those kinds of annotations, but to use it u must do:

 <serviceTask id="enroll-customer" name="enroll-customer" 
           activiti:delegateExpression="#{registry}"/>

etc.

You might ahve a sophisticated business process with 10 serviceTasks and their 'delegateExpression' would all be '#{registry}'! It's ugly…

Your feedback is very appreciated.

Re: Next steps for the spring component integration

tombaeyens — Tue, 08 Mar 2011 08:03:26 GMT

@ActivitiMapping( serviceTask = 'enroll-customer') public void handleEnrollCustomerTask( @ProcessInstance ProcessInstance pi, @ProcessVariable( "customerId") Long customerId ) { }

The idea makes perfect sense and totally rocks.

We should not bind this automagically to a serviceTask. This behavior should be marked clearly with an activity type like this:

<serviceTask id="enroll-customer" activiti:type="spring-annotation-mapping">
Do you think that is a good solution too, Josh?

Re: Next steps for the spring component integration

meyerd — Tue, 08 Mar 2011 10:48:06 GMT

Hi,

Well in the spirit of the Inversion of Control Pattern I think Josh's Proposal goes in the right direction. It depends on your perspective of course: "who is controlling whom?".
If you have the perspective that a process should contain as few technical details as possible, then it makes a lot of sense, because then you are building an Environment in which the process can run, leaving open the possibility to change that environment (ie. add different beans etc).

If the process.bpmn20.xml is you primary focus, then I would agree that sth. like

<serviceTask id="enroll-customer" activiti:type="spring-annotation-mapping">
or even

<serviceTask id="enroll-customer" name="enroll-customer" activiti:delegateExpression="#{…}"/>

Makes more sense.

Daniel