[ 
https://issues.apache.org/jira/browse/CXF-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robby Pelssers updated CXF-6523:
--------------------------------
    Description: 
An explicit Soap header is causing issues due to having the same QName as the 
wrapped Soap body 

   <wsdl:message name="ARAuthenticate">
      <wsdl:part element="s0:AuthenticationInfo" name="parameters"/>
   </wsdl:message>

   <wsdl:message name="GetWorkOrdersListSoapIn">
      <wsdl:part element="s0:GetWorkOrdersList" name="parameters"/>
   </wsdl:message>

 This results in a MessageInfo object with 1 messagePart and 1 outOfbandPart, 
both having the same QName.

Problem is that in the WrapperClassInInterceptor we loop over 
messageInfo.getMessageParts which actually returns the combined list of 
messageParts and outOfBandParts.

Now for the header part with QName  "{urn:VF_WorkOrders}parameters" we do a 
lookup wrappedMessageInfo.getMessagePart(part.getName()) which incorrectly 
retrieves the wrapped input messagePart.



                for (MessagePartInfo part : messageInfo.getMessageParts()) {
                    if 
(Boolean.TRUE.equals(part.getProperty(ReflectionServiceFactoryBean.HEADER))) {
                        MessagePartInfo mpi = 
wrappedMessageInfo.getMessagePart(part.getName());
                        if (mpi != null && lst.hasValue(mpi)) {
                            count++;
                            newParams.put(part, lst.get(mpi));
                        } else if (mpi == null || mpi.getTypeClass() == null) {
                            //header, but not mapped to a param on the method
                            if (removes == null) {
                                removes = new ArrayList<Integer>();
                            }
                            removes.add(part.getIndex());
                        }
                    } else {
                        ++count;
                    }
                }



  was:
An explicit Soap header is causing issues due to having the same QName as the 
wrapped Soap body 

   <wsdl:message name="ARAuthenticate">
      <wsdl:part element="s0:AuthenticationInfo" name="parameters"/>
   </wsdl:message>

   <wsdl:message name="GetWorkOrdersListSoapIn">
      <wsdl:part element="s0:GetWorkOrdersList" name="parameters"/>
   </wsdl:message>

 This results in a MessageInfo object with 1 messagePart and 1 outOfbandPart, 
both having the same QName.

Problem is that in the WrapperClassInInterceptor we loop over 
messageInfo.getMessageParts which actually returns the combined list of 
messageParts and outOfBandParts.

Now for the header part with QName  "{urn:VF_WorkOrders}parameters" we do a 
lookup wrappedMessageInfo.getMessagePart(part.getName()) which retrieves the 
wrapped input messagePart.



                for (MessagePartInfo part : messageInfo.getMessageParts()) {
                    if 
(Boolean.TRUE.equals(part.getProperty(ReflectionServiceFactoryBean.HEADER))) {
                        MessagePartInfo mpi = 
wrappedMessageInfo.getMessagePart(part.getName());
                        if (mpi != null && lst.hasValue(mpi)) {
                            count++;
                            newParams.put(part, lst.get(mpi));
                        } else if (mpi == null || mpi.getTypeClass() == null) {
                            //header, but not mapped to a param on the method
                            if (removes == null) {
                                removes = new ArrayList<Integer>();
                            }
                            removes.add(part.getIndex());
                        }
                    } else {
                        ++count;
                    }
                }




> org.apache.cxf.interceptor.Fault: wrong number of arguments (due to explicit 
> soap header)
> -----------------------------------------------------------------------------------------
>
>                 Key: CXF-6523
>                 URL: https://issues.apache.org/jira/browse/CXF-6523
>             Project: CXF
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.7.11, 3.1.2
>            Reporter: Robby Pelssers
>            Priority: Critical
>         Attachments: workorders.wsdl
>
>
> An explicit Soap header is causing issues due to having the same QName as the 
> wrapped Soap body 
>    <wsdl:message name="ARAuthenticate">
>       <wsdl:part element="s0:AuthenticationInfo" name="parameters"/>
>    </wsdl:message>
>    <wsdl:message name="GetWorkOrdersListSoapIn">
>       <wsdl:part element="s0:GetWorkOrdersList" name="parameters"/>
>    </wsdl:message>
>  This results in a MessageInfo object with 1 messagePart and 1 outOfbandPart, 
> both having the same QName.
> Problem is that in the WrapperClassInInterceptor we loop over 
> messageInfo.getMessageParts which actually returns the combined list of 
> messageParts and outOfBandParts.
> Now for the header part with QName  "{urn:VF_WorkOrders}parameters" we do a 
> lookup wrappedMessageInfo.getMessagePart(part.getName()) which incorrectly 
> retrieves the wrapped input messagePart.
>                 for (MessagePartInfo part : messageInfo.getMessageParts()) {
>                     if 
> (Boolean.TRUE.equals(part.getProperty(ReflectionServiceFactoryBean.HEADER))) {
>                         MessagePartInfo mpi = 
> wrappedMessageInfo.getMessagePart(part.getName());
>                         if (mpi != null && lst.hasValue(mpi)) {
>                             count++;
>                             newParams.put(part, lst.get(mpi));
>                         } else if (mpi == null || mpi.getTypeClass() == null) 
> {
>                             //header, but not mapped to a param on the method
>                             if (removes == null) {
>                                 removes = new ArrayList<Integer>();
>                             }
>                             removes.add(part.getIndex());
>                         }
>                     } else {
>                         ++count;
>                     }
>                 }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to