Thanks for the feedback Raul! More inline...
On 21 October 2012 11:58, Raul Kripalani <r...@evosent.com> wrote:
> Hi James,
>
> The idea looks nice. I'm just a bit concerned about whether the concept
> steps on the toes of the interceptSendToEndpoint DSL to some extent?
>
> The interceptSTE DSL only triggers at the dispatch stage, not at the
> response, so it doesn't _fully wrap_ it. Perhaps we could extend the
> interceptSTE to provide a syntax like this:
>
> <interceptSendToEndpoint uri="seda:issueTicket">
> <before>
> <log message="Intercepted: ${body}" />
> <bean ref="abc" method="def" />
> </before>
> <after>
> <!-- only trigger if condition is true -->
> <xpath>/airline = 'Camel Airlines'</xpath>
> <log message="Intercepted response: ${body}" />
> </after>
> </interceptSendToEndpoint>
>
> If I'm not mistaken, this shortcoming exists ever since the AOP DSL was
> deprecated [1]?
>
> Anyway, back to Bindings. The concept is top notch, but it may confuse
> users to find so many ways in Camel of doing similar stuff (Binding,
> Intercept, EventNotifiers, etc.).
Yeah, it can be confusing when there are lots of ways of doing things;
though those all sound quite different things and different
motivations. EventNotifiers are all about being notified of events
from Camel as it runs; Bindings are about wrapping endpoints in kinds
of contract like Data Format or validation steps; Intercept allows you
to intercept any step at any point in any route; they all sound quite
well defined to me. That doesn't mean its not confusing mind you :)
Another way of saying the same thing is; I think for lots of use cases
a Binding (taking, say, a Data Format and an Endpoint together as a
single composite) will be easier to understand for many Camel users
than doing funky interceptor stuff which is quite hardcore ninja
stuff.
> IMHO, the benefits of Bindings against interceptSTE are the following:
>
> - Definition is local to the endpoint => with bindings, the
> before/after logic is defined closer to the endpoint; interceptors are
> defined "further away" from the endpoint: in the Camel Context.
> - Due to above, code readability and clarity may be better with Bindings
> in some cases, as the user doesn't have to dot back and forth to get the
> full picture.
> - Before / after semantics => interceptSTE cannot define actions after
> the endpoint dispatch returns
> - With Bindings, full interception logic (before, after) can be
> encapsulated inside a single Java class. With interceptSTE it's not
> possible. Maybe we can provide a syntax like
>
> <interceptSendToEndpoint uri="..." interceptorRef="myInterceptor" />
Yeah; I wonder if longer term Binding is a neater abstraction over
interceptSTE long term; though more work is required to make Bindings
nice DSL citizens. We could maybe unify/align things together a little
more in Camel 3?
--
James
-------
Red Hat
Email: jstra...@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration
