> The SOAP spec calls for the message to be only processed if it fully > understands all the mandatory parts. Sounds to me that your service > should never get called in this case.
+1!! This used to work fine, and apparently was broken when dims integrated a large patch on Dec 20, 2002: http://marc.theaimsgroup.com/?l=axis-dev&m=104040531426594&w=2 There used to be a "SOAPRequestHandler" which would check MUs after all request Handlers had run but before the pivot point - this change switched it to be a "SOAPResponseHandler" and to run after the pivot. This is badness. I should have looked closer at that patch at the time, and we should research why Andras did it that way. There are two ways to get the MU semantic Simon describes to work. First, you can make sure to check MUs before doing anything substantive. Second, you can make sure any work you do before MU checking is "rollbackable" and ensure that appropriate control flow happens to enable rolling this stuff back. While there is some call for handling the "rollback" situation anyway (even for non-MU faults), I think the "check first" approach is the generally better one, and in fact I think we should change the way we deal with MUs back to the way it was in a much earlier version of Axis. Each Handler keeps a list of which QNames it knows how to process, and the MU check can therefore be done very quickly before ANY Handlers are called. This is what the "canHandleBlock(qname)" API in Handler is for. We should fix this immediately - I'll volunteer to do so this weekend. Are people OK with switching back to the "pre-flight-check" for MU headers (my preferred fix)? --Glen
