camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Explanation of MEPs within Camel
Date Fri, 18 Apr 2008 10:22:22 GMT
On 17/04/2008, David Siefert <> wrote:
> Hello,
>  I could use some explanation of how MEPs are used within Camel.  I
>  understand the various Message Exchange Patterns (in, out, inout), but I am
>  having some trouble with how I design my processor.  I need to take an XML
>  document and move some of the information from the body to header
>  properties.  To do this I took the input message, parsed the body to get the
>  information I needed.  Then I set that data on the output message, and set a
>  body for the output message.  I created a test to verify the work was done,
>  but it fails.  I end up getting what looks like the input message.
>  Here is the test code snippet:
>   MockEndpoint result = // get mock...
>   result.expectedMessageCount(1);
>   result.expectedBodiesReceived("");
>  When I run the test, it will say:
>   INFO: Asserting: Endpoint[mock:result] is satisfied
>  But the test fails:
>   java.lang.AssertionError: mock:result Body of message: 0. Expected: <> but
>  was: <...(body of input message here)...>

I'm not quite sure whats gone wrong - I've added your example to
DavidSiefertTest in trunk and its working fine for me. Have a look at
the unit test and see if you can change the code to make it fail :)

BTW you using 1.3.0?

>  It doesn't really appear that it is even making assertions about the header
>  properties either.

I spotted the issue with that. You're using the .equals() method
rather than the .isEqualTo() method. Which basically means you're
comparing the assertion builder to a String which returns false and
doesnt' actually perform the assertion :)

BTW sometimes its easier to just assert how many messages you want, then call

List<Exchange> list = mockEndpoint.getReceivedExchanges()

and look inside them and do more regular JUnit / Hamcrest assertions

> I don't really understand the point of this if you
>  have an output message in the Exchange.  Wouldn't Camel automagically take
>  the output of the exchange and send it to its next destination?

Yes it does that.

For one way messaging, its overkill having the IN and OUT; though in
many request/response type environments its very handy having access
to both the IN and the OUT when it comes to marshalling the response

The current defaults in Camel are if you don't ever create an OUT
message, it'll just forward the IN message to the next component. Its
kinda confusing, but if you call exchange.getOut() it'll lazily create
an OUT message (which by default is empty).

I confess folks often trip up over this bit of convention over
configuration; I wonder if we can make the defaults a bit less


Open Source Integration

View raw message