[
https://issues.apache.org/jira/browse/CXF-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890729#action_12890729
]
William Tam commented on CXF-2902:
----------------------------------
I am concern that it will stop working with existing CXF clients if we
completely reject such WSDLs. We probably should leave it as is?
> Doc-lit, bare, multi part ("type" and not any) message gets rejected by
> DocLiteralInInterceptor
> -----------------------------------------------------------------------------------------------
>
> Key: CXF-2902
> URL: https://issues.apache.org/jira/browse/CXF-2902
> Project: CXF
> Issue Type: Bug
> Components: Core
> Reporter: William Tam
> Fix For: 2.3, 2.2.10
>
> Attachments: CXF-2902.patch
>
>
> I have a message defined as below in a WSDL. (Granted, it is not a WS-1
> Profile compliant WSDL).
> {code}
> <wsdl:message name="MPTestResponse">
> <wsdl:part name="Param1" type="xsd:int"/>
> <wsdl:part name="DefaultOutput" type="xsd:string"/>
> </wsdl:message>
> {code}
> If the service model is built from a WSDL and not from a service class, the
> MessagePartInfo's concrete name will not have a namespace. As the result,
> the SOAP message gets rejected incorrectly by DocLiteralInInterceptor due to
> findMessagePart() method returns null. In the findMessagePart() method, it
> adds a namespace to the read in message part (variable "name") if it does not
> have one. In the case of the"type" message part, it does not have a
> namespace. The problem is that the MessagePartInfo's concreteName does not
> have a namespace and the comparison (name.equals(p.getConcreteName()) will
> fail. (The "name" now has a namespace but the concrete name does not.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
