On Mon, May 2, 2011 at 2:59 PM, Javier Arias Losada <[email protected]> wrote: > done, > FYI : issue 3928 > https://issues.apache.org/jira/browse/CAMEL-3928 > one question... is this released in older versions like 2.2.0? or have I to > use my own patch?
Yep you need to patch your own 2.2.0 versions as we dont do patch releases at Apache for such old releases. > thank you. > javier arias. > > 2011/5/2 Claus Ibsen <[email protected]> > >> Hi >> >> Well spotted. Cane you create a JIRA ticket? >> >> >> On Mon, May 2, 2011 at 11:23 AM, Javier Arias Losada >> <[email protected]> wrote: >> > Hi all, >> > >> > I am implementing a traceability solution on camel. We need a fine >> grained >> > solution providing a lot of detail, so I am implementing my own custom >> > interceptor. >> > >> > What I want to do is trace each step in the routes and keep the >> > 'parent-child' relation between different exchanges (eg. different >> exchanges >> > inside the same route when in a split, etc). Also I want to print the >> > customId assigned to each step, so the steps are printed in user-friendly >> > way. >> > >> > I discovered what I think is a bug. I am not sure 100% it is a bug but >> this >> > is the behaviour I had expected... >> > >> > I am using camel 2.2.0 inside servicemix 3.3.2, but I think that this >> > behaviour is also found in latest camel version. >> > >> > In routes with a split step, when my wrapProcessorInInterceptors method >> is >> > called, the ProcessorDefinition<?> paremeter is referencing the Split >> > definition instead of steps inside it. >> > >> > For example, for the route: >> > >> > from("direct:a").routeId("route:a") >> > .split(xpath("//a/b")).id("task:split.products") >> > .log("*** splited ::: body : ${body} ").id("task:handle.that") >> > (*) >> > .setHeader("insplit",constant("in-split")) (*) >> > .end() >> > .log("* aftersplit ::: body : ${body}").id("task:after.split"); >> > >> > for steps inside the split (*) the ProcessorDefinition is referencing the >> > splitdefinition, while i think it should point to the log and setHeader >> > steps. >> > >> > It can be easily fixed, in class::: >> > >> > org.apache.camel.processor.DefaultChannel >> > >> > in the method initChannel, changing >> > >> > target = >> > strategy.wrapProcessorInInterceptors(routeContext.getCamelContext(), >> > outputDefinition, target, next); >> > >> > by this: >> > >> > target = >> > strategy.wrapProcessorInInterceptors(routeContext.getCamelContext(), >> > traceDef, target, next); >> > >> > Is this behaviour ok? is it well fixed? This is my first 'contribution' >> so >> > any advice and help will be more than well received. >> > >> > Thank you and best regards. >> > Javier Arias. >> > >> >> >> >> -- >> Claus Ibsen >> ----------------- >> FuseSource >> Email: [email protected] >> Web: http://fusesource.com >> CamelOne 2011: http://fusesource.com/camelone2011/ >> Twitter: davsclaus >> Blog: http://davsclaus.blogspot.com/ >> Author of Camel in Action: http://www.manning.com/ibsen/ >> > -- Claus Ibsen ----------------- FuseSource Email: [email protected] Web: http://fusesource.com CamelOne 2011: http://fusesource.com/camelone2011/ Twitter: davsclaus Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
