Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (3.9)
  3. Reference
  4. Using Non-MEL Expressions

  5. Non-MEL Expressions Configuration Reference

Non-MEL Expressions Configuration Reference

The Mule Expression Language (MEL) removes the need to use old expressions in Mule. Refer to Mule Expression Language MEL for details on how to use MEL. This page provides reference information for configuring pre-Mule 3.3 style expressions.

Expression Attributes

The XML configuration elements in Mule that support expressions have three common attributes that define the expression to execute, the evaluator to use, and the option of defining a custom evaluator.

Attribute Description

expression

The expression to evaluate. The syntax of this attribute changes depending on the evaluator being used.

evaluator

The expression evaluator to use. Expression evaluators must be registered with the following before they can be used:

ExpressionEvaluatorManager

Using the custom evaluator allows you to define your custom evaluator via the custom-evaluator attribute. Note that some evaluators such as Xpath, Groovy, and Bean are loaded from other Mule modules (XML and Scripting, respectively). These modules must be on your classpath before their evaluators can be used.

custom-evaluator

The name of a custom evaluator to use. This evaluator must be registered in the local registry before it can be used.

Expressions can be used in a number of other scenarios such as filters, routing, and endpoints.

Expression Syntax

There are two ways of specifying expressions depending on where the expression is being used. Typically, expression-based elements such as the expression transformer, expression filter, and expression-based routers such as the expression message splitter, have specific attributes for expression, evaluator, and custom-evaluator. For example:

<expression-filter evaluator="header" expression="my-header!=null"/>

For these elements, you can set only a single expression for the element. When defining expressions for things like property values, you can set multiple expressions using the following syntax:

#[<evaluator>:<expression>]

The syntax requires that you precede an expression with #[, and then define the evaluator followed by a colon (:) and the expression to execute. Finally, you terminate the expression with a ]. You can define multiple expressions as a string. For example:

<message-properties-transformer>
    <add-message-property name="GUID" value="#[string:#[xpath:/msg/header/ID]-#[xpath:/msg/body/@ref]]"/>
</message-properties-transformer>

For a list of available evaluators, see Expression Evaluator Reference below.

Optional Values

As of Mule 2.2, you can use an asterisk to indicate an optional property in the expression. For example the following expression would indicate that foo and car must be present, but bar is optional:

#[headers:foo,bar*,car]

Spring Property Placeholders and Expressions

Spring and Mule have had long-time support for property placeholders that allow developers to inject static properties into their configuration when their application starts up. The property values are defined in Java property files that are passed into the framework on start up. The following example shows a properties file that defines configuration information used by a Mule endpoint:

MyApplication.properties

web.proxy.host=192.168.2.2
web.proxy.port=8081

The Mule configuration file can embed these properties as placeholders.

<mule ...>
    <http:request-config name="request-config" host="${web.proxy.host}"
port="${web.proxy.port}"/>
</mule>

These property placeholders are resolved during the start-up phase of your application. Mule expressions are evaluated continuously for every message received or sent.

Expression Evaluator Reference

Following are the default expression evaluators that are loaded at runtime. Not all expression evaluators are supported by every type of expression-based object. For example, the attachment evaluator is available to routers but not filters.

Name Description

attachment

Not supported by expression filters.

Example: #[attachment:supporting-docs]

attachments

Returns a java.util.Map of attachments. Not supported by expression filters.

Example: #[attachments:attach1,attach2]

attachments-list

Returns a java.util.List of attachments objects. Not supported by expression filters. You can specify * to retrieve all attachments or a wildcard pattern to select attachments by name.

Example: #[attachments-list:attach1,attach2]

bean

The bean property expression. Use "." or "/" as element delimiter.

Example: #[bean:fruit.isWashed]

endpoint

Use endpointName.property. Not supported by expression filters.

Example: #[endpoint:myEP.address]

exception-type

Matches an exception type. Only supported by expression filters.

Example: #[exception-type:java.lang.RuntimeException]

function

Performs a function: now, date, datestamp, systime, uuid, hostname, ip, or count. Not supported by expression filters.

Example: #[function:datestamp:dd-MM-yyyy]

groovy

Evaluates the expression using the Groovy language.

Example: #[groovy:payload.fruit.washed]

header

Evaluates the specified part of the message header.

Example: #[header:Content-Type]

headers

Returns a java.util.Map of headers. Not supported by expression filters. You can specify #[headers:*] to get all headers.

Example: #[headers:Content-Type,Content-Length]

headers-list

Returns a java.util.List of header values. Not supported by expression filters.

Example: #[headers-list:Content-Type,Content-Length]

json

For expression syntax, see:

JsonExpressionEvaluator

Example: #[json://fruit]

json-node

As of Mule 3.1, returns the node object from the JSON expression as is. For expression syntax, see:

JsonExpressionEvaluator

Example: #[json-node://fruit]

jxpath

JXPath expression that works on both XML/DOM and Beans.

Example: #[jxpath:/fruit]

map-payload

Returns a value from within a java.util.Map payload. Not supported by expression filters.

Example: #[map-payload:key]

message

Available expressions are id, correlationId, correlationSequence, correlationGroupSize, replyTo, payload, encoding, and exception. Not supported by expression filters.

Example: #[message:correlationId]

ognl

Set the evaluator attribute on the <expression-filter> element to ognl when specifying an OGNL filter. Note: OGNL is deprecated in Mule 3.6 and will be removed in Mule 4.0.

Example: #[ognl:[MULE:0].equals(42)]

payload

If expression is provided, it’s a class to be class loaded. The class is the desired return type of the payload. See getPayload(Class) in:

MuleMessage

Not supported by expression filters.

Example: #[payload:com.foo.RequiredType]

payload-type

Matches the type of the payload. Only supported by expression filters.

Example: #[payload:java.lang.String]

process

Invokes a message processor within an expression. This processor can be any component, transformer, custom processor, processor chain or flow. This evaluator is most useful when used with a nested expression that determines the value that is processed by the referenced message processor.

Example: #[process:processorName:valueToProcess]

regex

Only supported by expression filters.

Example: #[regex:the quick brown (.*)]

string

Evaluates the expressions in the string.

Example: #[string:Value is #[xpath://foo] other value is #[header:foo].]

variable

Used for retrieving values of flow variables.

Example: #[variable:variableName]

wildcard

Only supported by expression filters.

Example: #[wildcard:*.txt]

xpath

The expression is an XPath expression.

Example: #[xpath://fruit]

xpath-node

Returns the node object from the XPath expression as is.

Example: #[xpath-node://fruit]

Expression Enricher Reference

The following are the default expression enrichers that are loaded at runtime.

Name Description

variable

Used for storing variable values in a flow.

Example: #[variable:variableName]

header

Adds/overwrites the specified message header.

Example: #[header:Content-Type]