On Wed, Dec 12, 2012 at 10:03 PM, Christian Müller <christian.muel...@gmail.com> wrote: > Ok, I reverted the change. > What's your suggested solution? > > The current behavior is not a good solution... >
Well for Camel 3.0 we have on the roadmap to refactor the message history eip, which essentially is also the tracer, as it would trace the history of the message being routed. With internal refactorings in the routing engine and whatnot, this should make it easier and better to implement. The current logic was in they very very beginning coarse grained. And was improved to trace with more details, and also better show the path taken (eg from -> to). Though this logic is a bit "stretched" eg to figure out when a split is ended and you continue routing after the splitting, or which predicate a content based router was chosen etc. Anyway the Traceable is intended for controlling the String that is shown in the tracer. And that is only intended for EIPs and end users processors etc. Not all the internal processors such as wrap / delegate / error handler / instrument / uow / ... and what we have. Though it ought to be possible to make a fix so an end user processor is shown in the tracer, regardless if JMX is enabled or not. But the bottom line ... is that in Camel 3.0 we have a better solution, and if we hit some "not easy to fix" in the 2.x, then so be it. > Best, > Christian > > On Wed, Dec 12, 2012 at 8:57 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > >> intended -- Claus Ibsen ----------------- Red Hat, Inc. FuseSource is now part of Red Hat Email: cib...@redhat.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
