On Wed, Jul 7, 2010 at 10:28 AM, Hadrian Zbarcea 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
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 wrote:
>> Fair enough, let's do that. I think beforeWrap is actually better though.
>> And then we document how it could/shoul
On Wed, Jul 7, 2010 at 10:07 AM, Hadrian Zbarcea 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 Defi
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 wrote:
>> That works quite well actually. What would be good though is if
On Wed, Jul 7, 2010 at 9:46 AM, Hadrian Zbarcea 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 h
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
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.
*
* This allows you to do any custo
On Wed, Jul 7, 2010 at 8:08 AM, Hadrian Zbarcea 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:
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
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 n
On Mon, Jul 5, 2010 at 5:53 PM, Mark Proctor 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
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:
Hi
Have you looked at org.apache.camel.spi.InterceptStrategy?
On Mon, Jul 5, 2010 at 5:00 PM, Mark Proctor 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
13 matches
Mail list logo
