On Fri, Apr 18, 2008 at 6:22 AM, James Strachan <[EMAIL PROTECTED]>
wrote:
> On 17/04/2008, David Siefert <[EMAIL PROTECTED]> 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
> 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
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://open.iona.com
>
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.
-David
