On 8/9/07, James Strachan <[EMAIL PROTECTED]> wrote:
> On 8/9/07, James Strachan <[EMAIL PROTECTED]> wrote:
> > On 8/9/07, Nick Outram <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > James.Strachan wrote:
> > > >
> > > >
> > > > Am just wondering the semantics of onPattern() really; as when I first
> > > > read your suggestion, in my mind I was thinking that onPattern() would
> > > > setup an interceptor. So maybe onPattern() needs some kind of
> > > > proceed() call in part of its route to indicate if/when it carries on
> > > > processing?
> > > >
> > > > e.g. how about this (making a slight change to the language)...
> > > >
> > > > onIntercept(anyPredicateGoesHere).to("seda:a").filter(somethingElse).proceed();
> > > >
> > > > from("seda:foo").to("seda:b");
> > > >
> > > > i.e. in the above we intercept the route, if the message matches
> > > > anyPredicateGoesHere, then its sent to "seda:a" and if somethingElse
> > > > matches, then it carries on to "seda:b". So it could go to "seda:a",
> > > > "seda:b" or both - depending on the evaluation of the two predicates.
> > > >
> > > > If you really just want it to go to "seda:a" or "seda:b" then you'd just
> > > > do...
> > > >
> > > > onIntercept(anyPredicateGoesHere).to("seda:a");
> > > >
> > > > from("seda:foo").to("seda:b");
> > > >
> > > > In both cases really, we're just putting Message Filter / Content
> > > > Based Router inside an interceptor; rather than in-place inside the
> > > > route (and allowing the default behaviour of interceptors to be
> > > > inherited on all child nodes of the DSL, so the interceptor would be
> > > > applied around all Processors in the chain).
> > > >
> > > > How's that sound?
> > > >
> > > >
> > > >
> > >
> > >
> > > onIntercept().choice()
> > > .when(anyPredicateGoesHere).to("seda:a")
> > > .when(somethingElse).to("seda:b", "seda:c")
> > > .when(somethingElseAgain).to("seda:d", proceed());
> > >
> > > from("seda:foo").process(new Enricher1()). process(new
> > > Enricher2()).to("seda:z");
> > >
> > > Reads:
> > > After from("seda:foo") or process(new Enricher1()) or process(new
> > > Enricher2()) if the message matches anyPredicateGoesHere then send to
> > > seda:a, if the message matches somethinElse then send it to seda:b and
> > > seda:c, if the message matches somethingElseAgain send it to seda:d and
> > > proceed on the current route, otherwise in all other cases just proceed;
> > > you
> > > could include an explicit otherwise clause but as this catches everything
> > > it
> > > would make your route pretty redundant.
> > >
> > > Also:
> > >
> > > onIntercept().filter(xpath("/[EMAIL
> > > PROTECTED]'James']")).to("mock:result",
> > > proceed());
> > >
> > > … after any processing on the route if the xpath matches then send the
> > > message to mock:result and proceed on the original route…
> > >
> > > and even:
> > >
> > > onIntercept().aggregator(header("JMSDestination")).to("activemq:someSlowTopicForGuis");
> > >
> > >
> > > Basically the onIntercept() applies the following message routing rules to
> > > all processes on routes it is registered with.
> > >
> > > If you really wanted to have fun you could have:
> > >
> > > onIntercept(interceptCriteria).filter(xpath("/[EMAIL
> > > PROTECTED]'James']")).to("mock:result",
> > > proceed());
> > >
> > > Which would only apply the intercept to processors matching the
> > > interceptCriteria…
> > >
> > > Thoughts? Am I raving ;-)
> >
> > Love it! :) Thanks for this awesome feedback!
> >
> > I'll see if I can have a go at implementing this later today unless
> > anyone beats me to it...
>
> OK I've a first cut of the interceptor route definition. BTW I raised
> a JIRA to track this...
> https://issues.apache.org/activemq/browse/CAMEL-92
>
> When actually implementing it, I found the method 'intercept()' to fit
> better with the existing code; so went with that to start with - is
> that OK with you?
>
> Now in a route builder if you do
>
> intercept().
>
> you are now defining an interceptor route, you must call proceed() to
> continue processing the underlying route. e.g.
>
> intercept().to("foo")
>
> would kinda replace the routing rules you have - so won't be too useful :)
>
> also if you do
>
> intercept(Predicate)
>
> the same rules apply - though if the predicate is false then there's a
> kinda explicit call to proceed() for you. If the predicate is true,
> its up to you to decide when/if to proceed() etc.
>
> Probably the easiest way to check I've implemented what you were
> thinking is to try the test cases; they are all here beginning with
> "Intercept*.java"
> https://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/
>
> i.e.
> https://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/InterceptRouteTest.java
> https://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/InterceptWithPredicateAndProceedRouteTest.java
> https://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/InterceptWithPredicateRouteTest.java
> https://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/InterceptWithoutProceedRouteTest.java
>
>
> Does this seem OK to you? Will start on the onError() now...
OK the onError() is done now too. Again when I actually came to code
it, I found it was a tad better to call it exception().
So you can now do
exception(FooException.class).to("seda:whatnot");
from("foo").process(something).to("seda:bar");
if the FooException is thrown then its sent to the "seda:whatnot"
queue; otherwise the default error handling takes place.
You can see this DSL in action using a variation of the ValidationTest...
https://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/ValidationWithExceptionTest.java
I'll ponder how easy its gonna be to use the DSL to customize
redelivery policy stuff on a per type basis too...
--
James
-------
http://macstrac.blogspot.com/
