[CAM-5624] If an expression doesn't start with '${' it is treated as a literal Created: 10/Mar/16  Updated: 10/Feb/17  Resolved: 16/Jan/17

Status: Closed
Project: camunda BPM
Component/s: engine
Affects Version/s: 7.4.1
Fix Version/s: 7.7.0, 7.6.2, 7.5.8, 7.7.0-alpha1

Type: Bug Report Priority: L3 - Default
Reporter: Neil Galarneau Assignee: Smirnov Roman
Resolution: Fixed Votes: 1
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes

Issue Links:
Title Keywords: expression language composite


When an expression starts with ${ it is evaluated with juel, but if it doesn't start that way, it appears not to evaluate it with juel.

For example, 'the result is $


' is output literally, with no evaluation.

The UEL documentation calls such an expression a composite expression.

Comment by Daniel Meyer [ 14/Mar/16 ]

Interesting. This whould need to be fixed in all the places where the code attempts to detect whether a provided String is an expression.
Would you be interested in contributing to this?

Comment by Hans Hübner [ 24/Nov/16 ]

When will this bug be fixed?

Why does the code need to detect whether a string is an expression? If it contains no JUEL constructs, it will be returned as-is, so "detecting" should be left to the JUEL evaluator rather than trying to replicate that functionality in the Camunda engine.

Comment by Daniel Meyer [ 24/Nov/16 ]

Hi Hans Hübner are you interested in contributing a solution?

Comment by Hans Hübner [ 24/Nov/16 ]

Are you really asking us to fix a bug in the software that we've licensed from you? I mean, I'm all for open source, but we're paying you for support, so this is not the kind of reply that I was expecting.

Comment by Daniel Meyer [ 24/Nov/16 ]

Hi Hans,

It seemed like you had an idea of how to fix this issue that is why I asked.

If you comment on a community issue you will be treated in the same way as any other community user. We are not checking whether you are a support customer or not. If you want to raise a support case you can open a support case and reference this issue.

Sorry for the inconvenience.


Comment by Hans Hübner [ 24/Nov/16 ]


maybe you should think about how you can recognize your paying enterprise customers.

Sorry for the inconvenience.

Comment by Johannes Heinemann [ 11/Jan/17 ]


the bug has now been fixed most cases. However, there are parameter where it is not possible to allow composite expressions. These cases are:

  • camunda:jobPriority/camunda:taskPriority: Those parameters are always evaluated to an integer. On the contrary, are composite expressions always evaluated to Strings. For example, If you would write a composite expression like jobPriority = "1+$ {'1'}

    instead of setting the number 2 you would set the string "1+1".

  • Scripts: In script languages like groovy it is also possible to use "${". Those scripts would then always be evaluated to composite expression. For instance, in groovy you can write the following line:
    text = "Your account shows currently a balance of $ {account - minus}

    If you write this in an inline script then the whole line would be interpreted as an expression instead of a groovy script.

  • config parameter in form field validation: As the leading "#{" or "${" is used to distinguish between if a class name or bean was stated.


Generated at Thu Jan 24 00:00:04 CET 2019 using JIRA 6.4.6#64021-sha1:33e5b454af4594f54560ac233c30a6e00459507e.