Mule 3 Expression Improvements

Motivation

Background:

Support for expression was introduced with Mule 2.2 in February 2009. This was new functionality that significantly simplified the use of filtering, transforming and routing using a single expression. Since the advent of cloud connectors expressions are heavily used to map from the messaging paradigm to the more RPC paradigm and select the values that will be used as parameters to invoke the connector.

While of great value over the time since expressions were introduced we have learnt about a number of issues in their usability, areas in which once improvement would greatly improve the usability of expressions in Mule.

Areas for Improvement

1) Syntax Consistency

Mule expression can be used in multiple places:

• Embedded within strings e.g. <logger message-""/> and endpoint 'address' attribute.
• Via expression/evaluator attributes on filter/transformer and other elements.
• Via a single 'expression' attribute on some other elements.

The attributes/syntax used in each of these places differs which is very confusing. Although we can't force consistency we can ensure that all places support a single syntax and that documentation/examples consistently uses a single consistent syntax.

See Mule Expressions Consistency

2) Redundant 'Mule' expression evaluator.

Since Mule 2.2 there has been a 'Mule' expression evaluator. In theory this make the use of expression more fluent by providing a shortcut to various other expression evaluators. This isn't the case though as there is no auto-complete and this it's just provides a second way of using the other evaluators.

See Deprecate Mule Expression Evaluator

3) Context of Groovy Expression Evaluators

The groovy expression evaluator is widely used instead of other expression evaluators because of their limitations or in order to perform logic in an expression rather than simply extract a value. While

See Improve Groovy Expression Evaluator Context

4) Expression Language

While the concept of having n expression evaluators with the ability to add custom evaluators is extensible it has a number of issues which all affect usability and in some cases the flexibility of use of expressions:

• The user needs to choose the appropriate expression evaluator
• It is not possible to compose expressions or compare result of two expressions
• The logic to compare values with literals is implemented in each evaluator. This means some don't support this and others are inconsistent.

A lot of people use the groovy expression evaluator to get around this, but this isn't that very intuitive and groovy has it's own issue.

See Mule Expression Language Dev

Migration Impact

All work done will be 100% backwards compatible. Documentation/examples will be updated to use the new approaches.

Studio Impact

These changes will impact studio, not at the pallette level but rather in the configuration panes of components that have expression-powered attributes.

Documentation Impact

The documentation for Mule expressions needs an overhaul once this work is done. All examples/documentation that uses expression elsewhere may need to be updated.