cancel
Showing results for 
Search instead for 
Did you mean: 

conditionExpression - how to access static methods

zhn
Champ in-the-making
Champ in-the-making
Hi there!

I'd like to use a static method call inside a conditional expression of my sequence flow. Is there any way to import classes to the juel expression context?
As far as I see, this context just knows about process variables and spring beans. Therefore I get an ActivitiException telling me: "Unknown property used in expression".

Let me explain my use case:
We have a couple of custom value types, e.g. "Money". Selecting a value, is done by calling a static valueOf-method like:
Money.valueOf("50 EUR")
. In addition the Money class provides some static methods for comparing and calculating values.

In my process I need to use an exclusive gateway checking some process variables of type Money:

<sequenceFlow id="checkSalary" sourceRef="1234" targetRef="4321">
    <conditionExpression xsi:type="tFormalExpression">${Money.less(salary, Money.valueOf("1500 EUR")}</conditionExpression>
</sequenceFlow>
The process variable "salary" is set before reaching this sequence flow. It should be compared to the value of 1500 EUR. "less" and "valueOf" are static methods of my java class "Money". The method "less" returns a Boolean.

Even if I'm changing the expression to
${Money.less(Money.valueOf("50 EUR", Money.valueOf("1500 EUR"))}
I'm getting the same exception. Thats absolutly clear… because the juel expression context does not know about my class Money. It just recons "Money" to be a property.

Is there a way to influence the ELContext of the JUEL to know about custom classes? Something like:
elContext.getImportHandler().importPackage("de.myexample.valuetypes");

I can't find a point to access or configure this context.

Thanks and Best regards!
Christin.
2 REPLIES 2

zhn
Champ in-the-making
Champ in-the-making
Hi again,

I worked on this problems for a couple of hours now and somehow solved it for my use case. Actually I couldn't find a point to access the ELContext of juel. However I found a workaround by implementing a service bean that wraps the expression evaluation. We do not use juel anymore but forward to a javax EL 3.0 glassfish implementation.

Maybe someone also wants to use this solution as well. So here's what our conditionExpression now looks like:

<sequenceFlow id="checkSalary" sourceRef="1234" targetRef="4321">
    <conditionExpression xsi:type="tFormalExpression">${javaxEL.eval("#{Money.less(salary, Money.valueOf(\"1500 EUR\")}", execution)}</conditionExpression>
</sequenceFlow>

My service bean (id="javaxEL") just forwards the evaluation to javax EL 3.0 glassfish implementation. The execution property point to the current variable scope:

public class ActivitiJavaxELConnector {
  public Object eval(String expr, VariableScope scope) {
      ExpressionFactory factory = ExpressionFactory.newInstance();
      ELContext context = new StandardELContext(factory);
     
      // import packages
      context.getImportHandler().importPackage("de.myexample.valuetypes"); 

      // add variables to context
      for (Entry<String, Object> v : scope.getVariables().entrySet()) {
        context.getELResolver().setValue(context, null, v.getKey(), v.getValue());
      }
     
      // evaluate
      return factory.createValueExpression(context, expr, Object.class).getValue(context);
  }
}

Haven't tested this for all use cases. Probably beans now cannot be used within the forwarded expression. However we don't use that in a conditionExpressions normally. Maybe this is not the smartest solution but it just works for us… 😉

Would be great if activiti could support the JSR-223 script engines to be used for conditionExpression as well… just like for script tasks. However I couldn't find something about that.

Best, Christin

jbarrez
Star Contributor
Star Contributor
> Would be great if activiti could support the JSR-223 script engines to be used for conditionExpression as well… just like for script tasks.
> However I couldn't find something about that.

No it does not support that. I do like the idea …