camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: Using Policy to alter Definitions before building
Date Wed, 07 Jul 2010 08:17:08 GMT
On Wed, Jul 7, 2010 at 10:07 AM, Hadrian Zbarcea <hzbarcea@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 <hzbarcea@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 <claus.ibsen@gmail.com>
wrote:
>>>>> On Wed, Jul 7, 2010 at 8:08 AM, Hadrian Zbarcea <hzbarcea@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 <mproctor@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

Mime
View raw message