Param Headers with mustUnderstand="true"

["Guillaume Sauthier (OW2)" <gu...@ow2.org>]

Hi all

I've got an issue with a mustUnderstand SOAP Header that is used as service
parameter (it's a method parameter of the implementor).
As the MustUnderstandInterceptor is placed in the PRE_PROTOCOL phase, the
binding operation is not known at this time (except if there is a
SOAPAction header somewhere), so
the HeaderUtil.getHeaderQNameInOperationParam(soapMessage) don't return the
QName of the param header.

That leads the MustUnderstandInterceptor to think that the header is not
understood by the current interceptor chain. And thus, it register a
SOAPFault in the Message, fault that will be thrown as an Exception in
the MustUnderstandEndingInterceptor.

I've got that issue as part of the Java EE TCK on OW2 JOnAS, running CXF
2.5.2 (but it's also broken with 2.3.9).

I've attached to this message a modification of a soap header test case
that show the problem.

After some analyzing, it appears the MU interceptor runs too early in the
chain : before one of the AbstractInDatabindingInterceptor sub-classes (I
presume that on of theses implementations is setting up the
BindingOperationInfo into the message).
I've done a (naive) workaround simply by chaging the phase of the MU
interceptor: from PRE_PROTOCOL to UNMARSHAL.
That fixes the test, but I don't know if this is the right approach, or if
that breaks the streaming, or anything else ... :)

Any advice ?
Should I create a bug with the testcase and my proposed patch ?

Thanks
--Guillaume

PS: Theses git patches are build against the 2.5.x-fixes branch of the
github CXF mirror

Re: Param Headers with mustUnderstand="true"

[akuhtz-2 <an...@gmail.com>]

Hi Dan, Hi Guillaume,

Any update on this issue? We've run into the same issue ... 

Best regards,
Andi

--
View this message in context: http://cxf.547215.n5.nabble.com/Param-Headers-with-mustUnderstand-true-tp5512612p5603351.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Re: Param Headers with mustUnderstand="true"

[Daniel Kulp <dk...@apache.org>]

Just a quick follow up...

I chatted with Guillaume a bit on IRC this morning about this.   I don't see a 
major issue with moving it.   The only potential problem I see is that this 
moves the interceptor to running after the JAX-WS SOAPHandlers which could 
potentially cause TCK issues with calls to the getMustUndertand methods 
occurring out of order.    Guillaume will run the TCK with this change and 
report back the results early next week.

Dan



On Friday, February 24, 2012 11:03:10 AM Guillaume Sauthier wrote:
> Hi all
> 
> I've got an issue with a mustUnderstand SOAP Header that is used as service
> parameter (it's a method parameter of the implementor).
> As the MustUnderstandInterceptor is placed in the PRE_PROTOCOL phase, the
> binding operation is not known at this time (except if there is a
> SOAPAction header somewhere), so
> the HeaderUtil.getHeaderQNameInOperationParam(soapMessage) don't return the
> QName of the param header.
> 
> That leads the MustUnderstandInterceptor to think that the header is not
> understood by the current interceptor chain. And thus, it register a
> SOAPFault in the Message, fault that will be thrown as an Exception in
> the MustUnderstandEndingInterceptor.
> 
> I've got that issue as part of the Java EE TCK on OW2 JOnAS, running CXF
> 2.5.2 (but it's also broken with 2.3.9).
> 
> I've attached to this message a modification of a soap header test case
> that show the problem.
> 
> After some analyzing, it appears the MU interceptor runs too early in the
> chain : before one of the AbstractInDatabindingInterceptor sub-classes (I
> presume that on of theses implementations is setting up the
> BindingOperationInfo into the message).
> I've done a (naive) workaround simply by chaging the phase of the MU
> interceptor: from PRE_PROTOCOL to UNMARSHAL.
> That fixes the test, but I don't know if this is the right approach, or if
> that breaks the streaming, or anything else ... :)
> 
> Any advice ?
> Should I create a bug with the testcase and my proposed patch ?
> 
> Thanks
> --Guillaume
> 
> PS: Theses git patches are build against the 2.5.x-fixes branch of the
> github CXF mirror
-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com