Warning
|
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. |
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 |
---|---|
|
The expression to evaluate. The syntax of this attribute will change depending on the evaluator being used. |
|
The expression evaluator to use. Expression evaluators must be registered with the following before they can be used: Using the custom evaluator allows you to define your custom evaluator via the |
|
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.
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, will 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.
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.
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 | Example | Comments |
---|---|---|
attachment |
|
Not supported by expression filters. |
attachments |
|
Returns a |
attachments-list |
|
Returns a |
bean |
|
The bean property expression. Use "." or "/" as element delimiter. |
endpoint |
|
Use |
exception-type |
|
Matches an exception type. Only supported by expression filters. |
function |
|
Performs a function: now, date, datestamp, systime, uuid, hostname, ip, or count. Not supported by expression filters. |
groovy |
|
Evaluates the expression using the Groovy language. |
header |
|
Evaluates the specified part of the message header. |
headers |
|
Returns a |
headers-list |
|
Returns a |
json |
|
For expression syntax, see: |
json-node |
|
As of Mule 3.1, returns the node object from the json expression as is. For expression syntax, see: |
jxpath |
|
JXPath expression that works on both XML/DOM and Beans. |
map-payload |
|
Returns a value from within a |
message |
|
Available expressions are |
ognl |
|
Set the |
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: Not supported by expression filters. |
payload-type |
|
Matches the type of the payload. Only supported by expression filters. |
process |
|
As of Mule 3.1.0, 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 will be processed by the referenced message processor. |
regex |
|
Only supported by expression filters. |
string |
|
Evaluates the expressions in the string. |
variable |
|
Used for retrieving values of flow variables. |
wildcard |
|
Only supported by expression filters. |
xpath |
|
The expression is an XPath expression. |
xpath-node |
|
As of Mule 2.2, returns the node object from the XPath expression as is. |
As of Mule 3.1.0, the following are the default expression enrichers that are loaded at runtime.
Name | Example | Comments |
---|---|---|
variable |
|
Used for storing variable values in a flow. |
header |
|
Adds/overwrites the specified message header. |