camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: Exception based routing
Date Thu, 09 Aug 2007 16:42:33 GMT
On 8/9/07, James Strachan <james.strachan@gmail.com> wrote:
> On 8/9/07, Nick Outram <apache@nickoutram.name> 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("/person[@name='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("/person[@name='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...

-- 
James
-------
http://macstrac.blogspot.com/

Mime
View raw message