...
Simple
...
Expression
...
Language
...
The
...
Simple
...
Expression
...
Language
...
was
...
a
...
really
...
simple
...
language
...
you
...
can
...
use,
...
but
...
has
...
since
...
grown
...
more
...
powerful.
...
Its
...
primarily
...
intended
...
for
...
being
...
a
...
really
...
small
...
and
...
simple
...
language
...
for
...
evaluating
...
...
and
...
...
without
...
requiring
...
any
...
new
...
dependencies
...
or
...
knowledge
...
of
...
...
;
...
so
...
its
...
ideal
...
for
...
testing
...
in
...
camel-core.
...
Its
...
ideal
...
to
...
cover
...
95%
...
of
...
the
...
common
...
use
...
cases
...
when
...
you
...
need
...
a
...
little
...
bit
...
of
...
expression
...
based
...
script
...
in
...
your
...
Camel
...
routes.
...
However
...
for
...
much
...
more
...
complex
...
use
...
cases
...
you
...
are
...
generally
...
recommended
...
to
...
choose
...
a
...
more
...
expressive
...
and
...
powerful
...
language
...
such
...
as:
- SpEL
- Mvel
- Groovy
- JavaScript
- EL
- OGNL
- one of the supported Scripting Languages
The simple language uses ${body
} placeholders for complex expressions where the expression contains constant literals. The ${ } placeholders can be omitted if the expression is only the token itself.
Tip | ||
---|---|---|
| ||
From Camel 2.5 onwards you can also use the alternative syntax which uses $simple{ } as placeholders. |
Tip | ||
---|---|---|
| ||
From Camel 2.8 onwards you can configure the result type of the Simple expression. For example to set the type as a |
Info | ||
---|---|---|
| ||
From Camel 2.2 onwards, the File Language is now merged with Simple language which means you can use all the file syntax directly within the simple language. |
Info | ||
---|---|---|
| ||
The Simple language have been improved from Camel 2.9 onwards to use a better syntax parser, which can do index precise error messages, so you know exactly what is wrong and where the problem is. For example if you have made a typo in one of the operators, then previously the parser would not be able to detect this, and cause the evaluation to be true. There is a few changes in the syntax which are no longer backwards compatible. When using Simple language as a Predicate then the literal text must be enclosed in either single or double quotes. For example: |
To get the body of the in message: "body"
, or "in.body"
or "${body}"
.
A complex expression must use ${ } placeholders, such as: "Hello ${in.header.name} how are you?"
.
You can have multiple functions in the same expression: "Hello ${in.header.name} this is ${in.header.me} speaking"
.
However you can not nest functions in Camel 2.8.x or older (i.e. having another ${ } placeholder in an existing, is not allowed).
From Camel 2.9 onwards you can nest functions.
Variables
Wiki Markup |
---|
* [SpEL] * [Mvel] * [Groovy] * [JavaScript] * [EL] * [OGNL] * one of the supported [Scripting Languages] The simple language uses {{$\{body}}} placeholders for complex expressions where the expression contains constant literals. The $\{ } placeholders can be omitted if the expression is only the token itself. {tip:title=Alternative syntax} From Camel 2.5 onwards you can also use the alternative syntax which uses $simple{ } as placeholders. This can be used in situations to avoid clashes when using for example Spring property placeholder together with Camel. {tip} {tip:title=Configuring result type} From Camel 2.8 onwards you can configure the result type of the [Simple] expression. For example to set the type as a {{java.lang.Boolean}} or a {{java.lang.Integer}} etc. {tip} {info:title=File language is now merged with Simple language} From Camel 2.2 onwards, the [File Language] is now merged with [Simple] language which means you can use all the file syntax directly within the simple language. {info} {info:title=Simple Language Changes in Camel 2.9 onwards} The [Simple] language have been improved from Camel 2.9 onwards to use a better syntax parser, which can do index precise error messages, so you know exactly what is wrong and where the problem is. For example if you have made a typo in one of the operators, then previously the parser would not be able to detect this, and cause the evaluation to be true. There is a few changes in the syntax which are no longer backwards compatible. When using [Simple] language as a [Predicate] then the literal text *must* be enclosed in either single or double quotes. For example: {{"$\{body} == 'Camel'"}}. Notice how we have single quotes around the literal. The old style of using {{"body"}} and {{"header.foo"}} to refer to the message body and header is @deprecated, and its encouraged to always use $\{ } tokens for the built-in functions. The range operator now requires the range to be in single quote as well as shown: {{"$\{header.zip} between '30000..39999'"}}. {info} To get the body of the in message: {{"body"}}, or {{"in.body"}} or {{"$\{body}"}}. A complex expression must use $\{ } placeholders, such as: {{"Hello $\{in.header.name} how are you?"}}. You can have multiple functions in the same expression: {{"Hello $\{in.header.name} this is $\{in.header.me} speaking"}}. However you can *not* nest functions in Camel 2.8.x or older (i.e. having another $\{ } placeholder in an existing, is not allowed). From *Camel 2.9* onwards you can nest functions. h3. Variables {div:class=confluenceTableSmall} || Variable || Type || Description || | camelId | String | *Camel 2.10:* the [CamelContext] name | | camelContext.*OGNL* | Object | *Camel 2.11:* the CamelContext invoked using a Camel OGNL expression. | | exchangeId | String | *Camel 2.3:* the exchange id | | id | String | the input message id | | body | Object | the input body | | in.body | Object | the input body | | body.*OGNL* | Object | *Camel 2.3:* the input body invoked using a Camel OGNL expression. | | in.body.*OGNL* | Object | *Camel 2.3:* the input body invoked using a Camel OGNL expression. | | bodyAs(_type_) | Type | *Camel 2.3:* Converts the body to the given type determined by its classname. The converted body can be null. | | mandatoryBodyAs(_type_) | Type | *Camel 2.5:* Converts the body to the given type determined by its classname, and expects the body to be not null. | | out.body | Object | the output body | | header.foo | Object | refer to the input foo header | | header\[foo\] | Object | *Camel 2.9.2:* refer to the input foo header | | headers.foo | Object | refer to the input foo header | | headers\[foo\] | Object | *Camel 2.9.2:* refer to the input foo header | | in.header.foo | Object | refer to the input foo header | | in.header\[foo\] | Object | *Camel 2.9.2:* refer to the input foo header | | in.headers.foo | Object | refer to the input foo header | | in.headers\[foo\] | Object | *Camel 2.9.2:* refer to the input foo header | | header.foo\[bar\] | Object | *Camel 2.3:* regard input foo header as a map and perform lookup on the map with bar as key | | in.header.foo\[bar\] | Object | *Camel 2.3:* regard input foo header as a map and perform lookup on the map with bar as key | | in.headers.foo\[bar\] | Object | *Camel 2.3:* regard input foo header as a map and perform lookup on the map with bar as key | | header.foo.*OGNL* | Object | *Camel 2.3:* refer to the input foo header and invoke its value using a Camel OGNL expression. | | in.header.foo.*OGNL* | Object | *Camel 2.3:* refer to the input foo header and invoke its value using a Camel OGNL expression. | | in.headers.foo.*OGNL* | Object | *Camel 2.3:* refer to the input foo header and invoke its value using a Camel OGNL expression. | | out.header.foo | Object | refer to the out header foo | | out.header\[foo\] | Object | *Camel 2.9.2:* refer to the out header foo | | out.headers.foo | Object | refer to the out header foo | | out.headers\[foo\] | Object | *Camel 2.9.2:* refer to the out header foo | | headerAs(_key_,_type_) | Type | *Camel 2.5:* Converts the header to the given type determined by its classname | | headers | Map | *Camel 2.9:* refer to the input headers | | in.headers | Map | *Camel 2.9:* refer to the input headers | | property.foo | Object | refer to the foo property on the exchange | | property\[foo\] | Object | *Camel 2.9.2:* refer to the foo property on the exchange | | property.foo.*OGNL* | Object | *Camel 2.8:* refer to the foo property on the exchange and invoke its value using a Camel OGNL expression. | | sys.foo | String | refer to the system property | | sysenv.foo | String | *Camel 2.3:* refer to the system environment | | exception | Object | *Camel 2.4:* Refer to the exception object on the exchange, is *null* if no exception set on exchange. Will fallback and grab caught exceptions ({{Exchange.EXCEPTION_CAUGHT}}) if the Exchange has any. | | exception.*OGNL* | Object | *Camel 2.4:* Refer to the exchange exception invoked using a Camel OGNL expression object | | exception.message | String | Refer to the exception.message on the exchange, is *null* if no exception set on exchange. Will fallback and grab caught exceptions ({{Exchange.EXCEPTION_CAUGHT}}) if the Exchange has any. | | exception.stacktrace | String | *Camel 2.6.* Refer to the exception.stracktrace on the exchange, is *null* if no exception set on exchange. Will fallback and grab caught exceptions ({{Exchange.EXCEPTION_CAUGHT}}) if the Exchange has any. | | date:_command:pattern_ | String | Date formatting using the {{java.text.SimpleDataFormat}} patterns. Supported commands are: *now* for current timestamp, *in.header.xxx* or *header.xxx* to use the Date object in the IN header with the key xxx. *out.header.xxx* to use the Date object in the OUT header with the key xxx.| | bean:_bean expression_ | Object | Invoking a bean expression using the [Bean] language. Specifying a method name you must use dot as separator. We also support the ?method=methodname syntax that is used by the [Bean] component. | | properties:_locations:key_ | String | *Camel 2.3:* Lookup a property with the given key. The {{locations}} option is optional. See more at [Using PropertyPlaceholder]. | | routeId | String | *Camel 2.11:* Returns the id of the current route the [Exchange] is being routed. | | threadName | String | *Camel 2.3:* Returns the name of the current thread. Can be used for logging purpose. | | ref:xxx | Object | *Camel 2.6:* To lookup a bean from the [Registry] with the given id. | | type:name.field | Object | *Camel 2.11:* To refer to a type or field by its FQN name. To refer to a field you can append .FIELD_NAME. For example you can refer to the constant field from Exchange as: {{org.apache.camel.Exchange.FILE_NAME}} |. | null | | *Camel 2.12.3:* represents a *null* | {div} h3. |
OGNL
...
expression
...
support
...
Available
...
as
...
of
...
Camel
...
2.3
Info |
---|
*
{info}
Camel's OGNL support is for invoking methods only. You cannot access fields.
Camel 2.11.1 *onwards we added special support for accessing the length field of Java arrays. |
The Simple and Bean language now supports a Camel OGNL notation for invoking beans in a chain like fashion.
Suppose the Message IN body contains a POJO which has a getAddress()
method.
Then you can use Camel OGNL notation to access the address object:
Code Block |
---|
{info} The [Simple] and [Bean] language now supports a Camel OGNL notation for invoking beans in a chain like fashion. Suppose the Message IN body contains a POJO which has a {{getAddress()}} method. Then you can use Camel OGNL notation to access the address object: {code} simple("${body.address}") simple("${body.address.street}") simple("${body.address.zip}") {code} |
Camel
...
understands
...
the
...
shorthand
...
names
...
for
...
getters,
...
but
...
you
...
can
...
invoke
...
any
...
method
...
or
...
use
...
the
...
real
...
name
...
such
...
as:
Code Block |
---|
} simple("${body.address}") simple("${body.getAddress.getStreet}") simple("${body.address.getZip}") simple("${body.doSomething}") {code} |
You
...
can
...
also
...
use
...
the
...
null
...
safe
...
operator
...
(
...
?.
...
)
...
to
...
avoid
...
NPE
...
if
...
for
...
example
...
the
...
body
...
does
...
NOT
...
have
...
an
...
address
Code Block |
---|
} simple("${body?.address?.street}") {code} |
Its
...
also
...
possible
...
to
...
index
...
in
...
Map
...
or
...
List
...
types,
...
so
...
you
...
can
...
do:
Code Block |
---|
} simple("${body[foo].name}") {code} |
To
...
assume
...
the
...
body
...
is
...
Map
...
based
...
and
...
lookup
...
the
...
value
...
with
...
foo
...
as
...
key,
...
and
...
invoke
...
the
...
getName
...
method
...
on
...
that
...
value.
Info | ||||
---|---|---|---|---|
| ||||
If the key has space, then you must enclose the key with quotes, for example 'foo bar': {info:key with spaces} If the key has space, then you *must* enclose the key with quotes, for example 'foo bar': {code}
|
You can access the Map
or List
objects directly using their key name (with or without dots) :
Code Block |
---|
{code} {info} You can access the {{Map}} or {{List}} objects directly using their key name (with or without dots) : {code} simple("${body[foo]}") simple("${body[this.is.foo]}") {code} |
Suppose
...
there
...
was
...
no
...
value
...
with
...
the
...
key
...
foo
...
then
...
you
...
can
...
use
...
the
...
null
...
safe
...
operator
...
to
...
avoid
...
the
...
NPE
...
as
...
shown:
Code Block |
---|
} simple("${body[foo]?.name}") {code} |
You
...
can
...
also
...
access
...
List
...
types,
...
for
...
example
...
to
...
get
...
lines
...
from
...
the
...
address
...
you
...
can
...
do:
Code Block |
---|
} simple("${body.address.lines[0]}") simple("${body.address.lines[1]}") simple("${body.address.lines[2]}") {code} |
There
...
is
...
a
...
special
...
last
...
keyword
...
which
...
can
...
be
...
used
...
to
...
get
...
the
...
last
...
value
...
from
...
a
...
list.
Code Block |
---|
} simple("${body.address.lines[last]}") {code} |
And
...
to
...
get
...
the
...
2nd
...
last
...
you
...
can
...
subtract
...
a
...
number,
...
so
...
we
...
can
...
use
...
last-1
...
to
...
indicate
...
this:
Code Block |
---|
} simple("${body.address.lines[last-1]}") {code} And the 3rd last is of course: { |
And the 3rd last is of course:
Code Block |
---|
code} simple("${body.address.lines[last-2]}") {code} |
And
...
you
...
can
...
call
...
the
...
size
...
method
...
on
...
the
...
list
...
with
Code Block |
---|
} simple("${body.address.lines.size}") {code} From *Camel |
From Camel 2.11.1
...
onwards
...
we
...
added
...
support
...
for
...
the
...
length
...
field
...
for
...
Java
...
arrays
...
as
...
well,
...
eg:
Code Block |
---|
} String[] lines = new String[]{"foo", "bar", "cat"}; exchange.getIn().setBody(lines); simple("There are ${body.length} lines") {code} |
And
...
yes
...
you
...
can
...
combine
...
this
...
with
...
the
...
operator
...
support
...
as
...
shown
...
below:
Code Block |
---|
} simple("${body.address.zip} > 1000") {code} h3. Operator support The parser is limited to only support a single |
Operator support
The parser is limited to only support a single operator.
To enable it the left value must be enclosed in ${ }. The syntax is:
Code Block |
---|
operator. To enable it the left value must be enclosed in $\{ }. The syntax is: {code} ${leftValue} OP rightValue {code} |
Where
...
the
...
rightValue
...
can
...
be
...
a
...
String
...
literal
...
enclosed
...
in
...
'
...
'
...
,
...
null
...
,
...
a
...
constant
...
value
...
or
...
another
...
expression
...
enclosed
...
in
...
$
...
{
...
}.
Info | ||||
---|---|---|---|---|
| =
| |||
}
There *must *be spaces around the operator. |
Camel will automatically type convert the rightValue type to the leftValue type, so its able to eg. convert a string into a numeric so you can use > comparison for numeric values.
The following operators are supported:
Operator | Description |
---|---|
== | equals |
> | greater than |
>= | greater than or equals |
< | less than |
<= | less than or equals |
!= | not equals |
contains | For testing if contains in a string based value |
not contains | For testing if not contains in a string based value |
regex | For matching against a given regular expression pattern defined as a String value |
not regex | For not matching against a given regular expression pattern defined as a String value |
in | For matching if in a set of values, each element must be separated by comma. |
not in | For matching if not in a set of values, each element must be separated by comma. |
is | For matching if the left hand side type is an instanceof the value. |
not is | For matching if the left hand side type is not an instanceof the value. |
range | For matching if the left hand side is within a range of values defined as numbers: |
not range | For matching if the left hand side is not within a range of values defined as numbers: |
And the following unary operators can be used:
Operator | Description |
---|---|
++ | Camel 2.9: To increment a number by one. The left hand side must be a function, otherwise parsed as literal. |
-- | Camel 2.9: To decrement a number by one. The left hand side must be a function, otherwise parsed as literal. |
\ | Camel 2.9.3 to 2.10.x To escape a value, eg \$, to indicate a $ sign. Special: Use \n for new line, \t for tab, and \r for carriage return. Notice: Escaping is not supported using the File Language. Notice: From Camel 2.11 onwards the escape character is no longer support, but replaced with the following three special escaping. |
\n | Camel 2.11: To use newline character. |
\t | Camel 2.11: To use tab character. |
\r | Camel 2.11: To use carriage return character. |
And the following logical operators can be used to group expressions:
Operator | Description |
---|---|
and | deprecated use && instead. The logical and operator is used to group two expressions. |
or | deprecated use || instead. The logical or operator is used to group two expressions. |
&& | Camel 2.9: The logical and operator is used to group two expressions. |
|| | Camel 2.9: The logical or operator is used to group two expressions. |
Info | ||
---|---|---|
| ||
In Camel 2.4 or older the |
The syntax for AND is:
Code Block |
---|
{info} Camel will automatically type convert the rightValue type to the leftValue type, so its able to eg. convert a string into a numeric so you can use > comparison for numeric values. The following operators are supported: || Operator || Description || | == | equals || | > | greater than | | >= | greater than or equals | | < | less than | | <= | less than or equals | | != | not equals | | contains | For testing if contains in a string based value | | not contains | For testing if not contains in a string based value | | regex | For matching against a given regular expression pattern defined as a String value | | not regex | For not matching against a given regular expression pattern defined as a String value | | in | For matching if in a set of values, each element must be separated by comma. | | not in | For matching if not in a set of values, each element must be separated by comma. | | is | For matching if the left hand side type is an instanceof the value. | | not is | For matching if the left hand side type is not an instanceof the value. | | range | For matching if the left hand side is within a range of values defined as numbers: {{from..to}}. From *Camel 2.9* onwards the range values must be enclosed in single quotes. | | not range | For matching if the left hand side is not within a range of values defined as numbers: {{from..to}}. From *Camel 2.9* onwards the range values must be enclosed in single quotes. | And the following unary operators can be used: || Operator || Description || | \+\+ | *Camel 2.9:* To increment a number by one. The left hand side must be a function, otherwise parsed as literal. | | \-\- | *Camel 2.9:* To decrement a number by one. The left hand side must be a function, otherwise parsed as literal. | | \ | *Camel 2.9.3 to 2.10.x* To escape a value, eg \$, to indicate a $ sign. Special: Use \n for new line, \t for tab, and \r for carriage return. *Notice:* Escaping is *not* supported using the [File Language]. *Notice:* From Camel 2.11 onwards the escape character is no longer support, but replaced with the following three special escaping. | | \n | *Camel 2.11:* To use newline character. | | \t | *Camel 2.11:* To use tab character. | | \r | *Camel 2.11:* To use carriage return character. | And the following logical operators can be used to group expressions: || Operator || Description || | and | *deprecated* use && instead. The logical and operator is used to group two expressions. || | or | *deprecated* use \|\| instead. The logical or operator is used to group two expressions. || | && | *Camel 2.9:* The logical and operator is used to group two expressions. || | \|\| | *Camel 2.9:* The logical or operator is used to group two expressions. || {info:title=Using and,or operators} In *Camel 2.4 or older* the {{and}} or {{or}} can only be used *once* in a simple language expression. From *Camel 2.5* onwards you can use these operators multiple times. {info} The syntax for AND is: {code} ${leftValue} OP rightValue and ${leftValue} OP rightValue {code} |
And
...
the
...
syntax
...
for
...
OR
...
is:
Code Block |
---|
} ${leftValue} OP rightValue or ${leftValue} OP rightValue {code} |
Some
...
examples:
Code Block |
---|
} simple("${in.header.foo} == 'foo'") // here Camel will type convert '100' into the type of in.header.bar and if its an Integer '100' will also be converter to an Integer simple("${in.header.bar} == '100'") simple("${in.header.bar} == 100") // 100 will be converter to the type of in.header.bar so we can do > comparison simple("${in.header.bar} > 100") {code} {info:title=Comparing with different types} When you compare with different types such as String and int, then you have to take a bit care. Camel will use the type from the left hand side as 1st priority. And fallback to the right hand side type if both values couldn't be compared based on that type. This means you can flip the values to enforce a specific type. Suppose the bar value above is a String. Then you can flip the equation: {code} |
Info | |||
---|---|---|---|
| |||
When you compare with different types such as String and int, then you have to take a bit care. Camel will use the type from the left hand side as 1st priority. And fallback to the right hand side type if both values couldn't be compared based on that type.
which then ensures the int type is used as 1st priority. This may change in the future if the Camel team improves the binary comparison operations to prefer numeric types over String based. It's most often the String type which causes problem when comparing with numbers. |
Code Block |
---|
{info} {code} // testing for null simple("${in.header.baz} == null") // testing for not null simple("${in.header.baz} != null") {code} And a bit more advanced example where the right value is another expression {code") |
And a bit more advanced example where the right value is another expression
Code Block |
---|
} simple("${in.header.date} == ${date:now:yyyyMMdd}") simple("${in.header.type} == ${bean:orderService?method=getOrderType}") {code} |
And
...
an
...
example
...
with
...
contains,
...
testing
...
if
...
the
...
title
...
contains
...
the
...
word
...
Camel
Code Block |
---|
} simple("${in.header.title} contains 'Camel'") {code} |
And
...
an
...
example
...
with
...
regex,
...
testing
...
if
...
the
...
number
...
header
...
is
...
a
...
4
...
digit
...
value:
Code Block |
---|
} simple("${in.header.number} regex '\\d{4}'") {code} |
And
...
finally
...
an
...
example
...
if
...
the
...
header
...
equals
...
any
...
of
...
the
...
values
...
in
...
the
...
list.
...
Each
...
element
...
must
...
be
...
separated
...
by
...
comma,
...
and
...
no
...
space
...
around.
...
This
...
also
...
works
...
for
...
numbers
...
etc,
...
as
...
Camel
...
will
...
convert
...
each
...
element
...
into
...
the
...
type
...
of
...
the
...
left
...
hand
...
side.
Code Block |
---|
} simple("${in.header.type} in 'gold,silver'") {code} |
And
...
for
...
all
...
the
...
last
...
3
...
we
...
also
...
support
...
the
...
negate
...
test
...
using
...
not:
Code Block |
---|
} simple("${in.header.type} not in 'gold,silver'") {code} |
And
...
you
...
can
...
test
...
if
...
the
...
type
...
is
...
a
...
certain
...
instance,
...
eg
...
for
...
instance
...
a
...
String
Code Block |
---|
} simple("${in.header.type} is 'java.lang.String'") {code} |
We
...
have
...
added
...
a
...
shorthand
...
for
...
all
...
java.lang
...
types
...
so
...
you
...
can
...
write
...
it
...
as:
Code Block |
---|
} simple("${in.header.type} is 'String'") {code} |
Ranges
...
are
...
also
...
supported.
...
The
...
range
...
interval
...
requires
...
numbers
...
and
...
both
...
from
...
and
...
end
...
are
...
inclusive.
...
For
...
instance
...
to
...
test
...
whether
...
a
...
value
...
is
...
between
...
100
...
and
...
199:
Code Block |
---|
} simple("${in.header.number} range 100..199") {code} |
Notice
...
we
...
use
...
..
...
in
...
the
...
range
...
without
...
spaces.
...
Its
...
based
...
on
...
the
...
same
...
syntax
...
as
...
Groovy.
...
From
...
Camel
...
2.9
...
onwards
...
the
...
range
...
value
...
must
...
be
...
in
...
single
...
quotes
Code Block |
---|
} simple("${in.header.number} range '100..199'") {code} {tip:title=Can be used in Spring XML} As the Spring XML does not have all the power as the Java DSL with all its various builder methods, you have to resort to use some other languages for testing with simple operators. Now you can do this with the simple language. In the sample below we want to test if the header is a widget order: {code:xml}") |
Tip | |||||||
---|---|---|---|---|---|---|---|
| |||||||
As the Spring XML does not have all the power as the Java DSL with all its various builder methods, you have to resort to use some other languages
|
Using and / or
If you have two expressions you can combine them with the and
or or
operator.
Tip | ||
---|---|---|
| ||
Use && or || from Camel 2.9 onwards. |
For instance:
Code Block |
---|
from> {code} {tip} h4. Using and / or If you have two expressions you can combine them with the {{and}} or {{or}} operator. {tip:title=Camel 2.9 onwards} Use && or \|\| from Camel 2.9 onwards. {tip} For instance: {code} simple("${in.header.title} contains 'Camel' and ${in.header.type'} == 'gold'") {code} |
And
...
of
...
course
...
the
...
or
...
is
...
also
...
supported.
...
The
...
sample
...
would
...
be:
Code Block |
---|
} simple("${in.header.title} contains 'Camel' or ${in.header.type'} == 'gold'") {code} *) |
Notice:
...
Currently
...
and
...
or
...
or
...
can
...
only
...
be
...
used
...
once
...
in
...
a
...
simple
...
language
...
expression.
...
This
...
might
...
change
...
in
...
the
...
future.
...
So
...
you
...
cannot
...
do:
Code Block |
---|
}
simple("${in.header.title} contains 'Camel' and ${in.header.type'} == 'gold' and ${in.header.number} range 100..200")
|
Samples
In the Spring XML sample below we filter based on a header value:
Code Block | ||||
---|---|---|---|---|
| ||||
{code} h3. Samples In the Spring XML sample below we filter based on a header value: {code:xml} <from uri="seda:orders"> <filter> <simple>${in.header.foo}</simple> <to uri="mock:fooOrders"/> </filter> </from> {code} |
The
...
Simple
...
language
...
can
...
be
...
used
...
for
...
the
...
predicate
...
test
...
above
...
in
...
the
...
...
...
pattern,
...
where
...
we
...
test
...
if
...
the
...
in
...
message
...
has
...
a
...
foo
...
header
...
(a
...
header
...
with
...
the
...
key
...
foo
...
exists).
...
If
...
the
...
expression
...
evaluates
...
to
...
true
...
then
...
the
...
message
...
is
...
routed
...
to
...
the
...
mock:fooOrders
...
endpoint,
...
otherwise
...
its
...
lost
...
in
...
the
...
deep
...
blue
...
sea .
The same example in Java DSL:
Code Block | ||||
---|---|---|---|---|
| ||||
;). The same example in Java DSL: {code:java} from("seda:orders") .filter().simple("${in.header.foo}").to("seda:fooOrders"); {code} |
You
...
can
...
also
...
use
...
the
...
simple
...
language
...
for
...
simple
...
text
...
concatenations
...
such
...
as:
Code Block | ||||
---|---|---|---|---|
| ||||
{code:java} from("direct:hello").transform().simple("Hello ${in.header.user} how are you?").to("mock:reply"); {code} |
Notice
...
that
...
we
...
must
...
use
...
$
...
{
...
}
...
placeholders
...
in
...
the
...
expression
...
now
...
to
...
allow
...
Camel
...
to
...
parse
...
it
...
correctly.
...
And
...
this
...
sample
...
uses
...
the
...
date
...
command
...
to
...
output
...
current
...
date.
Code Block | ||||
---|---|---|---|---|
| ||||
{code:java} from("direct:hello").transform().simple("The today is ${date:now:yyyyMMdd} and its a great day.").to("mock:reply"); {code} |
And
...
in
...
the
...
sample
...
below
...
we
...
invoke
...
the
...
bean
...
language
...
to
...
invoke
...
a
...
method
...
on
...
a
...
bean
...
to
...
be
...
included
...
in
...
the
...
returned
...
string:
Code Block | ||||
---|---|---|---|---|
| ||||
{code:java} from("direct:order").transform().simple("OrderId: ${bean:orderIdGenerator}").to("mock:reply"); {code} |
Where
...
orderIdGenerator
...
is
...
the
...
id
...
of
...
the
...
bean
...
registered
...
in
...
the
...
...
.
...
If
...
using
...
Spring
...
then
...
its
...
the
...
Spring
...
bean
...
id.
...
If
...
we
...
want
...
to
...
declare
...
which
...
method
...
to
...
invoke
...
on
...
the
...
order
...
id
...
generator
...
bean
...
we
...
must
...
prepend
...
.method
...
name
...
such
...
as
...
below
...
where
...
we
...
invoke
...
the
...
generateId
...
method.
Code Block | ||||
---|---|---|---|---|
| ||||
{code:java} from("direct:order").transform().simple("OrderId: ${bean:orderIdGenerator.generateId}").to("mock:reply"); {code} |
We
...
can
...
use
...
the
...
?method=methodname
...
option
...
that
...
we
...
are
...
familiar
...
with
...
the
...
...
component
...
itself:
Code Block | ||||
---|---|---|---|---|
| ||||
{code:java} from("direct:order").transform().simple("OrderId: ${bean:orderIdGenerator?method=generateId}").to("mock:reply"); {code} And from Camel |
And from Camel 2.3
...
onwards
...
you
...
can
...
also
...
convert
...
the
...
body
...
to
...
a
...
given
...
type,
...
for
...
example
...
to
...
ensure
...
its
...
a
...
String
...
you
...
can
...
do:
Code Block | ||||
---|---|---|---|---|
| ||||
{code:xml} <transform> <simple>Hello ${bodyAs(String)} how are you?</simple> </transform> {code} |
There
...
are
...
a
...
few
...
types
...
which
...
have
...
a
...
shorthand
...
notation,
...
so
...
we
...
can
...
use
...
String
...
instead
...
of
...
java.lang.String
...
.
...
These
...
are:
...
byte[],
...
String,
...
Integer,
...
Long
...
.
...
All
...
other
...
types
...
must
...
use
...
their
...
FQN
...
name,
...
e.g.
...
org.w3c.dom.Document
...
.
...
Its
...
also
...
possible
...
to
...
lookup
...
a
...
value
...
from
...
a
...
header
...
Map
...
in
...
Camel
...
2.3
...
onwards:
Code Block | ||||
---|---|---|---|---|
| ||||
{code:xml} <transform> <simple>The gold value is ${header.type[gold]}</simple> </transform> {code} |
In
...
the
...
code
...
above
...
we
...
lookup
...
the
...
header
...
with
...
name
...
type
...
and
...
regard
...
it
...
as
...
a
...
java.util.Map
...
and
...
we
...
then
...
lookup
...
with
...
the
...
key
...
gold
...
and
...
return
...
the
...
value.
...
If
...
the
...
header
...
is
...
not
...
convertible
...
to
...
Map
...
an
...
exception
...
is
...
thrown.
...
If
...
the
...
header
...
with
...
name
...
type
...
does
...
not
...
exist
...
null
...
is
...
returned.
...
From
...
Camel
...
2.9
...
onwards
...
you
...
can
...
nest
...
functions,
...
such
...
as
...
shown
...
below:
Code Block | ||||
---|---|---|---|---|
| ||||
{code:xml} <setHeader headerName="myHeader"> <simple>${properties:${header.someKey}}</simple> </setHeader> {code} h4. Referring to constants or enums *Available as of Camel 2.11* Suppose you have an enum for customers |
Referring to constants or enums
Available as of Camel 2.11
Suppose you have an enum for customers
Wiki Markup |
---|
{snippet:id=e1|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/Customer.java}
|
And
...
in
...
a
...
...
...
...
we
...
can
...
use
...
the
...
...
language
...
to
...
refer
...
to
...
this
...
enum,
...
to
...
check
...
the
...
message
...
which
...
enum
...
it
...
matches.
Wiki Markup |
---|
{snippet:id=e1|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/CBRSimpleTypeTest.java} h3. |
Using
...
new
...
lines
...
or
...
tabs
...
in
...
XML
...
DSLs
...
Available
...
as
...
of
...
Camel
...
2.9.3
...
From
...
Camel
...
2.9.3
...
onwards
...
its
...
easier
...
to
...
specify
...
new
...
lines
...
or
...
tabs
...
in
...
XML
...
DSLs
...
as
...
you
...
can
...
escape
...
the
...
value
...
now
Code Block | ||||
---|---|---|---|---|
| ||||
{code:xml} <transform> <simple>The following text\nis on a new line</simple> </transform> {code} h3. Setting result type *Available as of Camel 2.8* You can now provide a result type to the [Simple] expression, which means the result of the evaluation will be converted to the desired type. This is most useable to define types such as booleans, integers, etc. For example to set a header as a boolean type you can do: {code} |
Setting result type
Available as of Camel 2.8
You can now provide a result type to the Simple expression, which means the result of the evaluation will be converted to the desired type. This is most useable to define types such as booleans, integers, etc.
For example to set a header as a boolean type you can do:
Code Block |
---|
.setHeader("cool", simple("true", Boolean.class))
{code}
|
And
...
in
...
XML
...
DSL
Code Block | ||||
---|---|---|---|---|
| ||||
{code:xml} <setHeader headerName="cool"> <!-- use resultType to indicate that the type should be a java.lang.Boolean --> <simple resultType="java.lang.Boolean">true</simple> </setHeader> {code} h3. Changing function start and end tokens *Available as of Camel |
Changing function start and end tokens
Available as of Camel 2.9.1
...
You
...
can
...
configure
...
the
...
function
...
start
...
and
...
end
...
tokens
...
-
...
${
...
}
...
using
...
the
...
setters
...
changeFunctionStartToken
...
and
...
changeFunctionEndToken
...
on
...
SimpleLanguage
...
,
...
using
...
Java
...
code.
...
From
...
Spring
...
XML
...
you
...
can
...
define
...
a
...
<bean>
...
tag
...
with
...
the
...
new
...
changed
...
tokens
...
in
...
the
...
properties
...
as
...
shown
...
below:
Code Block | ||||
---|---|---|---|---|
| ||||
{code:xml} <!-- configure Simple to use custom prefix/suffix tokens --> <bean id="simple" class="org.apache.camel.language.simple.SimpleLanguage"> <property name="functionStartToken" value="["/> <property name="functionEndToken" value="]"/> </bean> {code} |
In
...
the
...
example
...
above
...
we
...
use
...
[
...
]
...
as
...
the
...
changed
...
tokens.
...
Notice
...
by
...
changing
...
the
...
start/end
...
token
...
you
...
change
...
those
...
in
...
all
...
the
...
Camel
...
applications
...
which
...
share
...
the
...
same
...
camel-core
...
on
...
their
...
classpath.
...
For
...
example
...
in
...
an
...
OSGi
...
server
...
this
...
may
...
affect
...
many
...
applications,
...
where
...
as
...
a
...
Web
...
Application
...
as
...
a
...
WAR
...
file
...
it
...
only
...
affects
...
the
...
Web
...
Application.
...
Loading
...
script
...
from
...
external
...
resource
...
Available
...
as
...
of
...
Camel
...
2.11
...
You
...
can
...
externalize
...
the
...
script
...
and
...
have
...
Camel
...
load
...
it
...
from
...
a
...
resource
...
such
...
as
...
"classpath:"
...
,
...
"file:"
...
,
...
or
...
"http:"
...
.
...
This
...
is
...
done
...
using
...
the
...
following
...
syntax:
...
"resource:scheme:location"
...
,
...
eg
...
to
...
refer
...
to
...
a
...
file
...
on
...
the
...
classpath
...
you
...
can
...
do:
Code Block |
---|
}
.setHeader("myHeader").simple("resource:classpath:mysimple.txt")
|
Setting Spring beans to Exchange properties
Available as of Camel 2.6
You can set a spring bean into an exchange property as shown below:
Code Block | ||||
---|---|---|---|---|
| ||||
{code} h3. Setting Spring beans to Exchange properties *Available as of Camel 2.6* You can set a spring bean into an exchange property as shown below: {code:xml} <bean id="myBeanId" class="my.package.MyCustomClass" /> ... <route> ... <setProperty propertyName="monitoring.message"> <simple>ref:myBeanId</simple> </setProperty> ... </route> {code} h3. Dependencies The [Simple] language is part of * |
Dependencies
The Simple language is part of camel-core
...
.