axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject Re: AxisEngine.checkMustUnderstand enforcing actor/roles?
Date Tue, 06 Mar 2007 20:52:50 GMT
Hi dims, Michael:

It is certainly true that role support is quite lacking so far in Axis2 
- I'll commit to cleaning this all up over the next week or so.  The 
main reason to differentiate the SOAP versions is to throw the correct 
fault - I think Axis1 dealt a lot better in some ways with the different 
SOAP versions (see org.apache.axis.soap.SOAPConstants), and we should 
probably implement something similar for A2.  This lets you write clean 
code and keep the version-specific stuff hidden underneath another class.

That said, the checkMustUnderstand() code is definitely doing the wrong 
thing right now.  The correct logic should be:

for (each header that IS targeted to me) {
    if (!processed and mustUnderstand==true) {
        throw version-specific-MU-Fault

The first cut of "is targeted to me" is something like "has no role, the 
'next' role, or is the ultimate receiver role".  The next version is to 
support a configurable list of role URIs.

Thanks for noticing this - clearly we need better tests here as well. 
Deepal and I were focusing on the Phase concept for that checkin you 
reference, and didn't pay enough attention to the MU piece.


Davanum Srinivas wrote:
> Glen,
> Could you please take a look at this one? Since Deepal is out and your
> name pops up in the original check-in :)
> -- dims
> On 3/5/07, Michael Rheinheimer <> wrote:
>> Hi, I have a few questions about the MustUnderstand SOAP header 
>> attribute processing logic in the AxisEngine.  Any help is 
>> appreciated.  What I see in the AxisEngine.checkMustUnderstand (at 
>> least up to SVN rev 512819) is that if the MustUnderstand header 
>> attribute is there, the following occurs:
>>  (1)  if not SOAP 1.1, header must have a role block, and that role 
>> block must be NEXT
>>  (2)  if SOAP 1.1, header may be null, but if it is not, then it must 
>> be NEXT
>>  I'm not sure why we would be doing this, except that possibly the 
>> support for the three standard roles is incomplete (SOAP 1.2, section 
>> 2.2:  
>>  The 
>> comments in the method declare support for only NEXT.  If my searching 
>> is correct, it appears deepal committed the version with the comments:
>> 2005-12-11 svn commit: r355917 [1/3] - in /webservices/axis2/tru 
>> axis-dev deepal
>>  Anybody have any insight into this?  Any plans to support the other 
>> two roles?  Why is the logic different for !SOAP1.1 than for SOAP1.1?
>>  Thanks!
>>  mike

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message