How to access fields in java service task

[sk8192]

If I have the following task definition:

    <serviceTask id="myServiceTask" name="My Service" activiti:expression="#{myService.myMethod(execution)}" activiti:resultVariableName="result">
      <extensionElements>
        <activiti:field name="testField">
          <activiti:string>testing123</activiti:string>
        </activiti:field>
      </extensionElements>
    </serviceTask>
‍‍‍‍‍‍‍‍‍

which corresponds to this java class:

@Component("myServiceTask")
public class MyServiceTask {
  public String myMethod(DelegateExecution execution) {
    // do something with testField
    return "";
  }
}
‍‍‍‍‍‍‍‍‍

How can I obtain the value of testField (i.e. "testing123") within the Java class?

[ronald_van_kuij]

You can't afaik when using expressions… Put the 'field' as a param in the extression and it will be passed in you method.

[sk8192]

That's what I was afraid of. Oh well.

Thanks, Ronald.

[frederikherema1]

Ronald is right, you can't use field-injection on activiti:expression (since the expression resolves to a method-call and NOT a callable object.

Can't you just pass in the arguments you want in the method-call expression itself?

[ronald_van_kuij]

Frederik,

That is what I mentioned as well, but internally we got the feedback that this is 'less intuitive' for the some people in the designer. But having the designer construct an expression based on 'fields' where fields are put in the method call in the order they are in would help a little, but the business people still would need to know the order of the parameters…  This limits the use of custom components in the designer drastically… (unfortunately)

[frederikherema1]

As the activiti:expression functionality requires knowledge of the context of the application and it's beans/methods, I don't see an immediate use for Business-analysts. If people (devs) want to offer well-know building-blocks for analysts/other people to use, I see these solutions:
-  Using a JavaDelegate with field Injection (which in turn, can delegate to one or more bean/method-calls hiding complexity) OR
- A custom designer-extension (with the correct form on it, which generates a delegate-method call with correct parameters) more feasible.

So creating a method-call at design-time based on fields seems to be a very exotic use case and error-prone, imho. Nevertheless, it's indeed confusing that you can combine fields with activiti:expression and activiti:delegateExpression and ideally the "fields" should disappear from the UI in these cases