Should we continue the discussion here or in the jira? Not sure if I get your point. To me a policy is meant exactly for that: to wrap a part of a route and inject extra processing. The wrap method returns a Processor that does some stuff and at some point delegates to the inner Processor that represents the part of the route wrapped by the policy. As such one could chose to add another SendProcessor to achieve something like a wiretap, or a ThreadsProcessor, or a Throttler, or what not. It can be done by instantiating Processors, but not by manipulating the ast. Why not? This addition allows one to do in a simpler way, what is already possible.
Why would you -1 this? What's the harm? On Jul 7, 2010, at 1:05 AM, Claus Ibsen wrote: > Hi > > In the patch on the ticket > https://issues.apache.org/activemq/browse/CAMEL-2914 > > The processor which is passed into the wrap is just a dummy delegate. > This breaks the contract that its the actual processor being wrapped. > So now there is a different in semantic between the regular wrap and > the new wrap with the definition. This is really not good. > > I am inclined to vote -1 on this and look for the alternative solution > with the ProcessorCreater API > > > On Mon, Jul 5, 2010 at 5:00 PM, Mark Proctor <mproc...@codehaus.org> wrote: >> >> As well as using Policy to wrap the child processors, I'd like to be able to >> change/augment the child definitions before they are built. My current use >> case for this is so I can augment the DataFormats, with additional >> configurations. Additionally this Policy also takes care of setting the >> current context ClassLoader, but that already works fine with the existing >> Policy wrap api. >> >> API comptability is a problem, but as a sketch to what I'm trying to >> achieve, here is a change that while a little clunky (due api compatability) >> should achieve the job. This allows the wrap to still call the child >> Process, via the delegate, but to also inspect and change the child >> Definitions prior to building. >> >> public interface DefinitionAwarePolicy extends Policy { >> Processor wrap(RouteContext routeContext, >> ProcessorDefinition<ProcessorDefinition> processorDefinition, Processor >> processor); >> } >> >> PolicyDefinition. >> public Processor createProcessor(RouteContext routeContext) throws >> Exception { >> DelegateProcessor childProcessor = new DelegateProcessor(); >> >> Policy policy = resolvePolicy(routeContext); >> ObjectHelper.notNull(policy, "policy", this); >> Processor target; >> if ( policy instanceof Policy ) { >> target = policy.wrap(routeContext, childProcessor); >> } else { >> target = ((DefinitionAwarePolicy)policy).wrap(routeContext, >> this, childProcessor); >> } >> >> childProcessor.setProcessor( this.createChildProcessor(routeContext, >> true) ); >> >> // wrap the target so it becomes a service and we can manage its >> lifecycle >> WrapProcessor wrap = new WrapProcessor(target, childProcessor); >> return wrap; >> } >> -- >> View this message in context: >> http://camel.465427.n5.nabble.com/Using-Policy-to-alter-Definitions-before-building-tp696567p696567.html >> Sent from the Camel - Users mailing list archive at Nabble.com. >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Author of Camel in Action: http://www.manning.com/ibsen/ > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus
