On Fri, Apr 22, 2016 at 9:11 PM, Jeff Segal <jeffrey.se...@gmail.com> wrote:
> Actually, one thing I just considered was that the id() DSL doesn't appear
> to support an expression, so generating it dynamically may not be possible
> (something I was hoping to be able to do in a second weave spot). Right now
> I'm actually using the 'browse' component + recipient list for my test
> hook, e.g. .recipientList(simple("browse:${header.MyHeader}"))
>

You can use the toString weave where you can try to check if the
toString has "browse" etc.



> Then I set up intercepts in my test class for all of the browse recipients
> that I expect to exist.
>
> So, it looks like my best bet for replacing 'browse' there would be to use
> weaveByType(SplitDefinition.class).selectIndex(1) to intercept after my
> second split().
>
> Jeff
>
> On Fri, Apr 22, 2016 at 3:03 PM, Jeff Segal <jeffrey.se...@gmail.com> wrote:
>
>> Awesome, thanks Claus. I switched to using weaveById and got the exact
>> behavior that I wanted in my actual route (weaveByType could work too but
>> is a bit less explicit).
>>
>> For the benefit of others, this is how I'd switch my route DSL from what I
>> sent earlier:
>>
>> from("direct:start")
>>         .setBody().constant(someXml)
>>         .split().xpath(anXpathExpression)
>>             .setHeader("myHeader", constant(somethingObtainedFromXpath))
>>             .id("weaveHere")
>>             .split().xpath(anotherXpath)
>>                 .to("seda:result");
>>
>> Then in my test I'd use weaveById("weaveHere").after().to("mock:foo") to
>> perform my validations.
>>
>> Jeff
>>
>> On Fri, Apr 22, 2016 at 2:35 PM, Claus Ibsen <claus.ib...@gmail.com>
>> wrote:
>>
>>> On Fri, Apr 22, 2016 at 6:23 PM, Jeff Segal <jeffrey.se...@gmail.com>
>>> wrote:
>>> > Minh - that's exactly what I'm trying to do. The issue is that I don't
>>> have
>>> > a great hook to insert my advice where I want.
>>> >
>>> > Claus - here's a rough example:
>>> >
>>> > from("direct:start")
>>> >         .setBody().constant(someXml)
>>> >         .split().xpath(anXpathExpression)
>>> >             .setHeader("myHeader", constant(somethingObtainedFromXpath))
>>> >             .to("mock:polluted")
>>> >             .split().xpath(anotherXpath)
>>> >                 .to("seda:result");
>>> >
>>> >
>>> > Let's say that I wanted to write some tests that ensured that the first
>>> > xpath gave me what I wanted. I could just do what I've shown above and
>>> > throw a mock endpoint in there that I can use as an adviceWith
>>> > interceptSendTo hook, but I'm wondering if there's a better alternative
>>> > than that.
>>>
>>> If you assign ids, to you eips then you can use advice with to select
>>> and add after/before them etc.
>>> Or without id's you can do that based on EIPs type, such as split,
>>> setHeader etc.
>>>
>>> Take a look at those weaveById, weaveByType etc, and those selectors
>>> http://camel.apache.org/advicewith.html
>>>
>>> For example to add a mock before the 1st setHeader
>>>
>>> weaveByType(SetHeaderDefinition.class).before().to("mock:beforeMyHeader")
>>>
>>>
>>>
>>>
>>> >
>>> > Jeff
>>> >
>>> >
>>> >
>>> >
>>> > On Fri, Apr 22, 2016 at 6:58 AM, Claus Ibsen <claus.ib...@gmail.com>
>>> wrote:
>>> >
>>> >> On Thu, Apr 21, 2016 at 8:18 PM, Jeff Segal <jeffrey.se...@gmail.com>
>>> >> wrote:
>>> >> > I've got a route that I'd like to do some unit testing on at various
>>> >> > stages. It does a few splits, sets some headers, etc. The problem is
>>> that
>>> >> > there's no actual endpoint for me to intercept until the very end,
>>> but
>>> >> I'd
>>> >> > like to do some verification midway through.
>>> >> >
>>> >> > I suppose I could add arbitrary mock endpoints in key spots to use as
>>> >> > interceptSendTo hooks, but I'd rather not pollute my route with test
>>> >> > scaffolding like that. I've also tried using vanilla
>>> intercept().when()
>>> >> > calls but those end up casting too wide a net to be useful (or don't
>>> >> offer
>>> >> > a straightforward way for to intercept where and only where I want
>>> to).
>>> >> >
>>> >> > Is there a better alternative to solving this problem than injecting
>>> >> > arbitrary mocks into my production routes?
>>> >> >
>>> >>
>>> >> Can you provide an example. I think that would help understand what you
>>> >> explain.
>>> >>
>>> >>
>>> >> > Jeff
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Claus Ibsen
>>> >> -----------------
>>> >> http://davsclaus.com @davsclaus
>>> >> Camel in Action 2: https://www.manning.com/ibsen2
>>> >>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>
>>
>>



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Reply via email to