On Wed, Jul 7, 2010 at 8:08 AM, Hadrian Zbarcea <hzbar...@gmail.com> wrote: > Should we continue the discussion here or in the jira? >
IMHO mailing list is best as they are easier to search. Also a broader audience may listen and contribute. > 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? > The contract is different between the Policy and the DefinitionAwarePolicy In the former the processor parameter is the created processor In the latter the processor parameter is a "dummy delegate" because Mark's goal was to *manipulate* the definition *before* the actual processor is created. So he passes in a "dummy delegate" and then afterwards creates the actual processor, now that he has manipulated the definition. This is not intuitive and leads to surprises! Mark's goal is to manipulate the routes before they are created, to have it adapted to his environment (I assume related to JBoss). On a greater scheme I would rather introduce a SPI factory to register a custom factory where Mark can do his manipulation. All you have to do is to define a Spring bean with the custom hook and Camel will pick it up and use it. <bean id="customFactory" class="org.apache.camel.processor.CustomProcessorFactoryTest$MyFactory"/> Then the end user doesn't have to remember to add a policy or whatever. The routes can *stay as is*. > > 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 > > -- 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
