While developing flows with a recent Mule ESB there is a big chance you will make use of MEL in your configuration. Although this feature has added great benefits while developing Mule flows it sometimes drives me crazy. In this post I will show two examples which took me some time to get it working.
The first was when I was using an expression-transformer to get a part of an XML document as payload. The expression I tried first was:
<expression-transformer> <return-argument evaluator="xpath" expression="//test" /> </expression-transformer>
I used the following xml as an example input:
<root>
<test>
<elementA>bericht</elementA>
</test>
<test2>abc</test2>
</root>
This results in an empty payload, not a NullPayload but an empty String as payload.
However if I define my transformer like the following:
<expression-transformer expression="xpath('//test')"/>
it results in a Dom4J Object as payload with the following String content:
<test><elementA>bericht</elementA></test>
which was exacty what I needed. I haven’t checked the source code to see if it could be clarified or explained somehow but it is good to know this difference in behavior.
The other example I ran into had to do with checking if a message property existed in a choice expression. I wanted to see if a incoming message (SOAP/XML) had an attachment attached to it. This becomes visible in the Mule Message as a ‘cxf_attachments’ property at the INVOCATION scope. So I first tried it with the following MEL expression:
<when expression="#[header:INVOCATION:cxf_attachments?==null">
I also tried several alternatives of this expression but I couldn’t get it to work. So I used the ‘old-fashioned’ way that could be used before MEL was in place:
<when expression="message.getInvocationProperty('cxf_attachments') != null" evaluator="groovy">
This worked like a charm. So you see that although MEL does add nice features I sometimes find it difficult to determine how it behaves in certain situations.
The Pragmatic Integrator 