Hm, interesting... I looked up the definition of "to intercept":
#1 seize on its way; "The fighter plane was ordered to intercept an aircraft that had entered the country's airspace" #2 wiretap: tap a telephone or telegraph wire to get information; "The FBI was tapping the phone line of the suspected spy"; "Is this hotel room bugged?" It looks like you are interpreting it as #1 whereas the documentation (and I) interpreted is as #2. To me #2 looks more useful, especially when intersect is being called without a predicate (i.e. intercept everything). This is also what I used in the test. If it intercepts everything as in #1 then what is the use of building the route? And interpreting it as #1, I still don't fully understand my test cases: Why are there differences between interceptBefore and interceptAfter? Well, I can see it from the viewpoint of how camel must have implemented it. It looks like camel takes the first one in the built route, but it doesn't really make sense to me from a functional viewpoint. It is very well possible that I am missing a point here, but I like to learn what that point is :) And - as a sidepoint - actually what I was looking for when I stumbled on intercept was something similar to the intercept concept in AOP. So something general that could be plugged in, in an easy way. Step(x) -> Interceptor -> Step(x+1) So not an interceptor as an endpoint but one acting as a filter. In this case you can decide in the interceptor whether you want to use it as #1 or #2 (or change the body, add something to the header or whatever). Rintcius -- View this message in context: http://www.nabble.com/Some-questions-about-a-simple-setHeader-test-tp16467528s22882p16648405.html Sent from the Camel - Users mailing list archive at Nabble.com.
