You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Mark Proctor <mp...@codehaus.org> on 2010/07/05 17:00:30 UTC
Using Policy to alter Definitions before building
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.
Re: Using Policy to alter Definitions before building
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Jul 7, 2010 at 10:28 AM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> Thanks Claus,
>
> I can do it in the morning. It got kinda late.
>
I took the liberty to commit the changes in the trunk. What's missing
is wiki documentation.
Please take a look at the code to see if there is anything you can
spot that's not what we talked about or in need of a change.
Yeah I do think its night/early morning in the states right now, and
you haven't got to bed yet.
> Hadrian
>
> On Jul 7, 2010, at 4:17 AM, Claus Ibsen wrote:
>
>> On Wed, Jul 7, 2010 at 10:07 AM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>>> Fair enough, let's do that. I think beforeWrap is actually better though. And then we document how it could/should be used.
>>>
>>
>> Yeah great. There is already javadoc documentation.
>>
>> But maybe we should add a wiki page about Policy and DefinitionAwarePolicy.
>>
>>
>>> On Jul 7, 2010, at 3:51 AM, Claus Ibsen wrote:
>>>
>>>> On Wed, Jul 7, 2010 at 9:46 AM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>>>>> That works quite well actually. What would be good though is if we could find a better name for the beforeWrap, something that communicates the intent, something like updateDefinitions, something that would be more intuitive about how the interface should be used. Yeah, not easy to come with the right name :(
>>>>>
>>>>
>>>> Yeah naming a new class or method is not always that strait forward.
>>>>
>>>> However naming it *update* kinda implies that you *must* update the
>>>> definition. What if you intent is not to update it, but you may want
>>>> to do something else.
>>>> I think the before name in this case is a good name because its
>>>> invoked before we do the wrap.
>>>>
>>>> It could be named onBeforeWrap if people are more into the onXXX naming style.
>>>>
>>>>
>>>>
>>>>>
>>>>> On Jul 7, 2010, at 2:33 AM, Claus Ibsen wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> I just had a thought.
>>>>>>
>>>>>> I think we should modify the DefinitionAwarePolicy a bit to ensure the
>>>>>> contract stays the same.
>>>>>> This is what I propose
>>>>>>
>>>>>> public interface DefinitionAwarePolicy extends Policy {
>>>>>>
>>>>>> /**
>>>>>> * Callback invoked before the wrap.
>>>>>> * <p/>
>>>>>> * This allows you to do any custom logic before the processor is
>>>>>> wrapped. For example to
>>>>>> * manipulate the {@link
>>>>>> org.apache.camel.model.ProcessorDefinition definiton}
>>>>>> *
>>>>>> * @param routeContext the route context
>>>>>> * @param definition the processor definition
>>>>>> */
>>>>>> void beforeWrap(RouteContext routeContext, ProcessorDefinition<?>
>>>>>> definition);
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>> Then we have this beforeWrap method which is invoked before the wrap
>>>>>> method. This allows Mark / end users to manipulate the definition.
>>>>>> And then the wrap method from Policy is used to wrap it.
>>>>>>
>>>>>> Then the contract stays the same, and there is no surprises.
>>>>>>
>>>>>> This allows a nice and clean custom policy.
>>>>>>
>>>>>> public static class MyPolicy implements DefinitionAwarePolicy {
>>>>>>
>>>>>> private final String name;
>>>>>> private int invoked;
>>>>>>
>>>>>> public MyPolicy(String name) {
>>>>>> this.name = name;
>>>>>> }
>>>>>>
>>>>>> public int getInvoked() {
>>>>>> return invoked;
>>>>>> }
>>>>>>
>>>>>> public void beforeWrap(RouteContext routeContext,
>>>>>> ProcessorDefinition<?> definition) {
>>>>>> SetBodyDefinition bodyDef = (SetBodyDefinition)
>>>>>> definition.getOutputs().get(0);
>>>>>> bodyDef.setExpression(new ConstantExpression("body was altered"));
>>>>>> }
>>>>>>
>>>>>> public Processor wrap(final RouteContext routeContext, final
>>>>>> Processor processor) {
>>>>>> return new Processor() {
>>>>>> public void process(Exchange exchange) throws Exception {
>>>>>> invoked++;
>>>>>> exchange.getIn().setHeader(name, "was wrapped");
>>>>>> processor.process(exchange);
>>>>>> }
>>>>>> };
>>>>>> }
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 7, 2010 at 8:18 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>>>>> On Wed, Jul 7, 2010 at 8:08 AM, Hadrian Zbarcea <hz...@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 <mp...@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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>
>>>
>>
>>
>>
>> --
>> 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
Re: Using Policy to alter Definitions before building
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Thanks Claus,
I can do it in the morning. It got kinda late.
Hadrian
On Jul 7, 2010, at 4:17 AM, Claus Ibsen wrote:
> On Wed, Jul 7, 2010 at 10:07 AM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>> Fair enough, let's do that. I think beforeWrap is actually better though. And then we document how it could/should be used.
>>
>
> Yeah great. There is already javadoc documentation.
>
> But maybe we should add a wiki page about Policy and DefinitionAwarePolicy.
>
>
>> On Jul 7, 2010, at 3:51 AM, Claus Ibsen wrote:
>>
>>> On Wed, Jul 7, 2010 at 9:46 AM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>>>> That works quite well actually. What would be good though is if we could find a better name for the beforeWrap, something that communicates the intent, something like updateDefinitions, something that would be more intuitive about how the interface should be used. Yeah, not easy to come with the right name :(
>>>>
>>>
>>> Yeah naming a new class or method is not always that strait forward.
>>>
>>> However naming it *update* kinda implies that you *must* update the
>>> definition. What if you intent is not to update it, but you may want
>>> to do something else.
>>> I think the before name in this case is a good name because its
>>> invoked before we do the wrap.
>>>
>>> It could be named onBeforeWrap if people are more into the onXXX naming style.
>>>
>>>
>>>
>>>>
>>>> On Jul 7, 2010, at 2:33 AM, Claus Ibsen wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I just had a thought.
>>>>>
>>>>> I think we should modify the DefinitionAwarePolicy a bit to ensure the
>>>>> contract stays the same.
>>>>> This is what I propose
>>>>>
>>>>> public interface DefinitionAwarePolicy extends Policy {
>>>>>
>>>>> /**
>>>>> * Callback invoked before the wrap.
>>>>> * <p/>
>>>>> * This allows you to do any custom logic before the processor is
>>>>> wrapped. For example to
>>>>> * manipulate the {@link
>>>>> org.apache.camel.model.ProcessorDefinition definiton}
>>>>> *
>>>>> * @param routeContext the route context
>>>>> * @param definition the processor definition
>>>>> */
>>>>> void beforeWrap(RouteContext routeContext, ProcessorDefinition<?>
>>>>> definition);
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> Then we have this beforeWrap method which is invoked before the wrap
>>>>> method. This allows Mark / end users to manipulate the definition.
>>>>> And then the wrap method from Policy is used to wrap it.
>>>>>
>>>>> Then the contract stays the same, and there is no surprises.
>>>>>
>>>>> This allows a nice and clean custom policy.
>>>>>
>>>>> public static class MyPolicy implements DefinitionAwarePolicy {
>>>>>
>>>>> private final String name;
>>>>> private int invoked;
>>>>>
>>>>> public MyPolicy(String name) {
>>>>> this.name = name;
>>>>> }
>>>>>
>>>>> public int getInvoked() {
>>>>> return invoked;
>>>>> }
>>>>>
>>>>> public void beforeWrap(RouteContext routeContext,
>>>>> ProcessorDefinition<?> definition) {
>>>>> SetBodyDefinition bodyDef = (SetBodyDefinition)
>>>>> definition.getOutputs().get(0);
>>>>> bodyDef.setExpression(new ConstantExpression("body was altered"));
>>>>> }
>>>>>
>>>>> public Processor wrap(final RouteContext routeContext, final
>>>>> Processor processor) {
>>>>> return new Processor() {
>>>>> public void process(Exchange exchange) throws Exception {
>>>>> invoked++;
>>>>> exchange.getIn().setHeader(name, "was wrapped");
>>>>> processor.process(exchange);
>>>>> }
>>>>> };
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 7, 2010 at 8:18 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>>>> On Wed, Jul 7, 2010 at 8:08 AM, Hadrian Zbarcea <hz...@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 <mp...@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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>
>>
>
>
>
> --
> 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
Re: Using Policy to alter Definitions before building
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Jul 7, 2010 at 10:07 AM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> Fair enough, let's do that. I think beforeWrap is actually better though. And then we document how it could/should be used.
>
Yeah great. There is already javadoc documentation.
But maybe we should add a wiki page about Policy and DefinitionAwarePolicy.
> On Jul 7, 2010, at 3:51 AM, Claus Ibsen wrote:
>
>> On Wed, Jul 7, 2010 at 9:46 AM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>>> That works quite well actually. What would be good though is if we could find a better name for the beforeWrap, something that communicates the intent, something like updateDefinitions, something that would be more intuitive about how the interface should be used. Yeah, not easy to come with the right name :(
>>>
>>
>> Yeah naming a new class or method is not always that strait forward.
>>
>> However naming it *update* kinda implies that you *must* update the
>> definition. What if you intent is not to update it, but you may want
>> to do something else.
>> I think the before name in this case is a good name because its
>> invoked before we do the wrap.
>>
>> It could be named onBeforeWrap if people are more into the onXXX naming style.
>>
>>
>>
>>>
>>> On Jul 7, 2010, at 2:33 AM, Claus Ibsen wrote:
>>>
>>>> Hi
>>>>
>>>> I just had a thought.
>>>>
>>>> I think we should modify the DefinitionAwarePolicy a bit to ensure the
>>>> contract stays the same.
>>>> This is what I propose
>>>>
>>>> public interface DefinitionAwarePolicy extends Policy {
>>>>
>>>> /**
>>>> * Callback invoked before the wrap.
>>>> * <p/>
>>>> * This allows you to do any custom logic before the processor is
>>>> wrapped. For example to
>>>> * manipulate the {@link
>>>> org.apache.camel.model.ProcessorDefinition definiton}
>>>> *
>>>> * @param routeContext the route context
>>>> * @param definition the processor definition
>>>> */
>>>> void beforeWrap(RouteContext routeContext, ProcessorDefinition<?>
>>>> definition);
>>>>
>>>> }
>>>>
>>>>
>>>> Then we have this beforeWrap method which is invoked before the wrap
>>>> method. This allows Mark / end users to manipulate the definition.
>>>> And then the wrap method from Policy is used to wrap it.
>>>>
>>>> Then the contract stays the same, and there is no surprises.
>>>>
>>>> This allows a nice and clean custom policy.
>>>>
>>>> public static class MyPolicy implements DefinitionAwarePolicy {
>>>>
>>>> private final String name;
>>>> private int invoked;
>>>>
>>>> public MyPolicy(String name) {
>>>> this.name = name;
>>>> }
>>>>
>>>> public int getInvoked() {
>>>> return invoked;
>>>> }
>>>>
>>>> public void beforeWrap(RouteContext routeContext,
>>>> ProcessorDefinition<?> definition) {
>>>> SetBodyDefinition bodyDef = (SetBodyDefinition)
>>>> definition.getOutputs().get(0);
>>>> bodyDef.setExpression(new ConstantExpression("body was altered"));
>>>> }
>>>>
>>>> public Processor wrap(final RouteContext routeContext, final
>>>> Processor processor) {
>>>> return new Processor() {
>>>> public void process(Exchange exchange) throws Exception {
>>>> invoked++;
>>>> exchange.getIn().setHeader(name, "was wrapped");
>>>> processor.process(exchange);
>>>> }
>>>> };
>>>> }
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Jul 7, 2010 at 8:18 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>>> On Wed, Jul 7, 2010 at 8:08 AM, Hadrian Zbarcea <hz...@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 <mp...@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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>
>
--
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
Re: Using Policy to alter Definitions before building
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Fair enough, let's do that. I think beforeWrap is actually better though. And then we document how it could/should be used.
On Jul 7, 2010, at 3:51 AM, Claus Ibsen wrote:
> On Wed, Jul 7, 2010 at 9:46 AM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>> That works quite well actually. What would be good though is if we could find a better name for the beforeWrap, something that communicates the intent, something like updateDefinitions, something that would be more intuitive about how the interface should be used. Yeah, not easy to come with the right name :(
>>
>
> Yeah naming a new class or method is not always that strait forward.
>
> However naming it *update* kinda implies that you *must* update the
> definition. What if you intent is not to update it, but you may want
> to do something else.
> I think the before name in this case is a good name because its
> invoked before we do the wrap.
>
> It could be named onBeforeWrap if people are more into the onXXX naming style.
>
>
>
>>
>> On Jul 7, 2010, at 2:33 AM, Claus Ibsen wrote:
>>
>>> Hi
>>>
>>> I just had a thought.
>>>
>>> I think we should modify the DefinitionAwarePolicy a bit to ensure the
>>> contract stays the same.
>>> This is what I propose
>>>
>>> public interface DefinitionAwarePolicy extends Policy {
>>>
>>> /**
>>> * Callback invoked before the wrap.
>>> * <p/>
>>> * This allows you to do any custom logic before the processor is
>>> wrapped. For example to
>>> * manipulate the {@link
>>> org.apache.camel.model.ProcessorDefinition definiton}
>>> *
>>> * @param routeContext the route context
>>> * @param definition the processor definition
>>> */
>>> void beforeWrap(RouteContext routeContext, ProcessorDefinition<?>
>>> definition);
>>>
>>> }
>>>
>>>
>>> Then we have this beforeWrap method which is invoked before the wrap
>>> method. This allows Mark / end users to manipulate the definition.
>>> And then the wrap method from Policy is used to wrap it.
>>>
>>> Then the contract stays the same, and there is no surprises.
>>>
>>> This allows a nice and clean custom policy.
>>>
>>> public static class MyPolicy implements DefinitionAwarePolicy {
>>>
>>> private final String name;
>>> private int invoked;
>>>
>>> public MyPolicy(String name) {
>>> this.name = name;
>>> }
>>>
>>> public int getInvoked() {
>>> return invoked;
>>> }
>>>
>>> public void beforeWrap(RouteContext routeContext,
>>> ProcessorDefinition<?> definition) {
>>> SetBodyDefinition bodyDef = (SetBodyDefinition)
>>> definition.getOutputs().get(0);
>>> bodyDef.setExpression(new ConstantExpression("body was altered"));
>>> }
>>>
>>> public Processor wrap(final RouteContext routeContext, final
>>> Processor processor) {
>>> return new Processor() {
>>> public void process(Exchange exchange) throws Exception {
>>> invoked++;
>>> exchange.getIn().setHeader(name, "was wrapped");
>>> processor.process(exchange);
>>> }
>>> };
>>> }
>>>
>>> }
>>>
>>>
>>>
>>>
>>> On Wed, Jul 7, 2010 at 8:18 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>> On Wed, Jul 7, 2010 at 8:08 AM, Hadrian Zbarcea <hz...@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 <mp...@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
>>>>
>>>
>>>
>>>
>>> --
>>> 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
Re: Using Policy to alter Definitions before building
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Jul 7, 2010 at 9:46 AM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> That works quite well actually. What would be good though is if we could find a better name for the beforeWrap, something that communicates the intent, something like updateDefinitions, something that would be more intuitive about how the interface should be used. Yeah, not easy to come with the right name :(
>
Yeah naming a new class or method is not always that strait forward.
However naming it *update* kinda implies that you *must* update the
definition. What if you intent is not to update it, but you may want
to do something else.
I think the before name in this case is a good name because its
invoked before we do the wrap.
It could be named onBeforeWrap if people are more into the onXXX naming style.
>
> On Jul 7, 2010, at 2:33 AM, Claus Ibsen wrote:
>
>> Hi
>>
>> I just had a thought.
>>
>> I think we should modify the DefinitionAwarePolicy a bit to ensure the
>> contract stays the same.
>> This is what I propose
>>
>> public interface DefinitionAwarePolicy extends Policy {
>>
>> /**
>> * Callback invoked before the wrap.
>> * <p/>
>> * This allows you to do any custom logic before the processor is
>> wrapped. For example to
>> * manipulate the {@link
>> org.apache.camel.model.ProcessorDefinition definiton}
>> *
>> * @param routeContext the route context
>> * @param definition the processor definition
>> */
>> void beforeWrap(RouteContext routeContext, ProcessorDefinition<?>
>> definition);
>>
>> }
>>
>>
>> Then we have this beforeWrap method which is invoked before the wrap
>> method. This allows Mark / end users to manipulate the definition.
>> And then the wrap method from Policy is used to wrap it.
>>
>> Then the contract stays the same, and there is no surprises.
>>
>> This allows a nice and clean custom policy.
>>
>> public static class MyPolicy implements DefinitionAwarePolicy {
>>
>> private final String name;
>> private int invoked;
>>
>> public MyPolicy(String name) {
>> this.name = name;
>> }
>>
>> public int getInvoked() {
>> return invoked;
>> }
>>
>> public void beforeWrap(RouteContext routeContext,
>> ProcessorDefinition<?> definition) {
>> SetBodyDefinition bodyDef = (SetBodyDefinition)
>> definition.getOutputs().get(0);
>> bodyDef.setExpression(new ConstantExpression("body was altered"));
>> }
>>
>> public Processor wrap(final RouteContext routeContext, final
>> Processor processor) {
>> return new Processor() {
>> public void process(Exchange exchange) throws Exception {
>> invoked++;
>> exchange.getIn().setHeader(name, "was wrapped");
>> processor.process(exchange);
>> }
>> };
>> }
>>
>> }
>>
>>
>>
>>
>> On Wed, Jul 7, 2010 at 8:18 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>> On Wed, Jul 7, 2010 at 8:08 AM, Hadrian Zbarcea <hz...@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 <mp...@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
>>>
>>
>>
>>
>> --
>> 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
Re: Using Policy to alter Definitions before building
Posted by Hadrian Zbarcea <hz...@gmail.com>.
That works quite well actually. What would be good though is if we could find a better name for the beforeWrap, something that communicates the intent, something like updateDefinitions, something that would be more intuitive about how the interface should be used. Yeah, not easy to come with the right name :(
On Jul 7, 2010, at 2:33 AM, Claus Ibsen wrote:
> Hi
>
> I just had a thought.
>
> I think we should modify the DefinitionAwarePolicy a bit to ensure the
> contract stays the same.
> This is what I propose
>
> public interface DefinitionAwarePolicy extends Policy {
>
> /**
> * Callback invoked before the wrap.
> * <p/>
> * This allows you to do any custom logic before the processor is
> wrapped. For example to
> * manipulate the {@link
> org.apache.camel.model.ProcessorDefinition definiton}
> *
> * @param routeContext the route context
> * @param definition the processor definition
> */
> void beforeWrap(RouteContext routeContext, ProcessorDefinition<?>
> definition);
>
> }
>
>
> Then we have this beforeWrap method which is invoked before the wrap
> method. This allows Mark / end users to manipulate the definition.
> And then the wrap method from Policy is used to wrap it.
>
> Then the contract stays the same, and there is no surprises.
>
> This allows a nice and clean custom policy.
>
> public static class MyPolicy implements DefinitionAwarePolicy {
>
> private final String name;
> private int invoked;
>
> public MyPolicy(String name) {
> this.name = name;
> }
>
> public int getInvoked() {
> return invoked;
> }
>
> public void beforeWrap(RouteContext routeContext,
> ProcessorDefinition<?> definition) {
> SetBodyDefinition bodyDef = (SetBodyDefinition)
> definition.getOutputs().get(0);
> bodyDef.setExpression(new ConstantExpression("body was altered"));
> }
>
> public Processor wrap(final RouteContext routeContext, final
> Processor processor) {
> return new Processor() {
> public void process(Exchange exchange) throws Exception {
> invoked++;
> exchange.getIn().setHeader(name, "was wrapped");
> processor.process(exchange);
> }
> };
> }
>
> }
>
>
>
>
> On Wed, Jul 7, 2010 at 8:18 AM, Claus Ibsen <cl...@gmail.com> wrote:
>> On Wed, Jul 7, 2010 at 8:08 AM, Hadrian Zbarcea <hz...@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 <mp...@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
>>
>
>
>
> --
> 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
Re: Using Policy to alter Definitions before building
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I just had a thought.
I think we should modify the DefinitionAwarePolicy a bit to ensure the
contract stays the same.
This is what I propose
public interface DefinitionAwarePolicy extends Policy {
/**
* Callback invoked before the wrap.
* <p/>
* This allows you to do any custom logic before the processor is
wrapped. For example to
* manipulate the {@link
org.apache.camel.model.ProcessorDefinition definiton}
*
* @param routeContext the route context
* @param definition the processor definition
*/
void beforeWrap(RouteContext routeContext, ProcessorDefinition<?>
definition);
}
Then we have this beforeWrap method which is invoked before the wrap
method. This allows Mark / end users to manipulate the definition.
And then the wrap method from Policy is used to wrap it.
Then the contract stays the same, and there is no surprises.
This allows a nice and clean custom policy.
public static class MyPolicy implements DefinitionAwarePolicy {
private final String name;
private int invoked;
public MyPolicy(String name) {
this.name = name;
}
public int getInvoked() {
return invoked;
}
public void beforeWrap(RouteContext routeContext,
ProcessorDefinition<?> definition) {
SetBodyDefinition bodyDef = (SetBodyDefinition)
definition.getOutputs().get(0);
bodyDef.setExpression(new ConstantExpression("body was altered"));
}
public Processor wrap(final RouteContext routeContext, final
Processor processor) {
return new Processor() {
public void process(Exchange exchange) throws Exception {
invoked++;
exchange.getIn().setHeader(name, "was wrapped");
processor.process(exchange);
}
};
}
}
On Wed, Jul 7, 2010 at 8:18 AM, Claus Ibsen <cl...@gmail.com> wrote:
> On Wed, Jul 7, 2010 at 8:08 AM, Hadrian Zbarcea <hz...@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 <mp...@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
>
--
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
Re: Using Policy to alter Definitions before building
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Jul 7, 2010 at 8:08 AM, Hadrian Zbarcea <hz...@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 <mp...@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
Re: Using Policy to alter Definitions before building
Posted by Hadrian Zbarcea <hz...@gmail.com>.
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 <mp...@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
Re: Using Policy to alter Definitions before building
Posted by Claus Ibsen <cl...@gmail.com>.
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 <mp...@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
Re: Using Policy to alter Definitions before building
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Jul 5, 2010 at 5:53 PM, Mark Proctor <mp...@codehaus.org> wrote:
>
> On 05/07/2010 16:32, Claus Ibsen-2 [via Camel] wrote:
>> Hi
>>
>> Have you looked at org.apache.camel.spi.InterceptStrategy?
> Looking at the code, the child Processor instance is already created, so
> I'm not sure it would be safe to change the child definitions?
>
Ah you are looking for a hook into the processor creation process?
I wonder if we should introduce a SPI for that instead of turning
Policy into what it was not designed for.
Instead a ProcessorCreator SPI could be used. Finding a good name for
the class is always a challenge.
interface ProcessorCreatorStrategy {
Processor createChildProcessor(RouteContext routeContext,
ProcessorDefinition definition, boolean mandatory) throws Exception
}
There could be additional methods in the future so maybe a
ProcessorDefinitionStrategy is a better name?
Then you can leverage this callback to eavesdrop and do whatever you want.
> Mark
>>
>>
>> On Mon, Jul 5, 2010 at 5:00 PM, Mark Proctor <[hidden email]
>> </user/SendEmail.jtp?type=node&node=696580&i=0>> 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
>> <http://camel.465427.n5.nabble.com/Using-Policy-to-alter-Definitions-before-building-tp696567p696567.html?by-user=t>
>> > 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
>> <http://fusesource.com?by-user=t>
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>>
>>
>> ------------------------------------------------------------------------
>> View message @
>> http://camel.465427.n5.nabble.com/Using-Policy-to-alter-Definitions-before-building-tp696567p696580.html
>>
>> To unsubscribe from Using Policy to alter Definitions before building,
>> click here
>> < (link removed) ==>.
>>
>>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Using-Policy-to-alter-Definitions-before-building-tp696567p696584.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
Re: Using Policy to alter Definitions before building
Posted by Mark Proctor <mp...@codehaus.org>.
On 05/07/2010 16:32, Claus Ibsen-2 [via Camel] wrote:
> Hi
>
> Have you looked at org.apache.camel.spi.InterceptStrategy?
Looking at the code, the child Processor instance is already created, so
I'm not sure it would be safe to change the child definitions?
Mark
>
>
> On Mon, Jul 5, 2010 at 5:00 PM, Mark Proctor <[hidden email]
> </user/SendEmail.jtp?type=node&node=696580&i=0>> 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
> <http://camel.465427.n5.nabble.com/Using-Policy-to-alter-Definitions-before-building-tp696567p696567.html?by-user=t>
> > 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
> <http://fusesource.com?by-user=t>
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
>
> ------------------------------------------------------------------------
> View message @
> http://camel.465427.n5.nabble.com/Using-Policy-to-alter-Definitions-before-building-tp696567p696580.html
>
> To unsubscribe from Using Policy to alter Definitions before building,
> click here
> < (link removed) ==>.
>
>
--
View this message in context: http://camel.465427.n5.nabble.com/Using-Policy-to-alter-Definitions-before-building-tp696567p696584.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Using Policy to alter Definitions before building
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Have you looked at org.apache.camel.spi.InterceptStrategy?
On Mon, Jul 5, 2010 at 5:00 PM, Mark Proctor <mp...@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