camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Siefert" <>
Subject Re: Explanation of MEPs within Camel
Date Fri, 18 Apr 2008 15:22:50 GMT
On Fri, Apr 18, 2008 at 6:22 AM, James Strachan <>

> 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
> >  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
> back.
> 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
> confusing?
> --
> James
> -------
> Open Source Integration

I just upgraded to 1.3.0--not to resolve this issue, but because I needed
the XSLT component in camel-spring:1.3.0.

I also made changes to my assertions--instead of using equals() I use
isEqualTo() like you mentioned.  This now causes the test to fail
appropriately.  Do you think it will be helpful to log a warning message
when calling equals() in a class that ends with "Test" to help idiot-proof
the ValueBuilder?

To make the in/out thing a little less confusing I think just a little bit
of documentation is helpful.  I did see in the test sourcecode where if the
out message was not created (I vaguely remember this--maybe in the
MockEndpoint code?) it just returns the input message.

Thanks for you help!  I cannot say it enough: this framework is a lot of fun
to use--I am NOT being sarcastic.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message