Paul Fremantle wrote: > I don't know enough about the mustUnderstand handling in Axis2, but it > seems to me that we might also want to identify a Synapse instance as > a given role. > > In other words, if we are acting as an intermediary, we may be > implementing a specific role, and not the "ultimate receiver". So we > only need to understand the headers that are targeted at our role or > the "next" role.
Well I don't think Synapse can understand all the headers which has the Role next. Take this example. A sends a message to B and this message is mediated by Synapse (S). If A doesn't know about S, then he sends some headers, marked as mustUnderstand=true thinking B will understand them all. A ------ (S) ----- B But if S intercept this message and if S can not understand it, then Synapse engine is in trouble. So there are two basic solutions to this problem. 1. To hack Axis2 itself to bypass mustUnderstand processing. This is very bad, IMO. Axis2 is a SOAP processor and it MUST adhere to the basics of SOAP. 2. As Saminda suggested, mark all the headers as processed. This is how mustUnderstand processing work in Axis2. If a handler can understand a header, then it should set a header as processed. At the end of the chain, Axis2 engine gets all the headers which mustUnderstand=true, and checks whether all of them have the processed flag set. If even one fails its a mustUnderstand check error (See AxisEngine.java:80) So what Synapse can do is set all the headers as processed, before Axis2 engine does the mustUnderstand checking. I think thats what Saminda had proposed and I also +1 that. -- Chinthaka
signature.asc
Description: OpenPGP digital signature
