[ http://issues.apache.org/jira/browse/BEEHIVE-746?page=all ]
Jeremiah Johnson updated BEEHIVE-746:
-------------------------------------
Attachment: BEEHIVE-746.tar
This (BEEHIVE-746.tar) is a lame excuse for a repro. By using the following
steps, you can use this to show you some WSDLs that I think are incorrect.
Note that the build script assumes that you have BEEHIVE_HOME set; if you
don't, then manually edit build.properties or call with a beehive.home
parameter.
tar xf BEEHIVE-746.tar
ant -f BEEHIVE-746/WEB-INF/src/build.xml clean build war
mv BEEHIVE-746.war $CATALINA_HOME/webapps
http://localhost:8080/BEEHIVE-746/
> WSDL generated for headers inconsistent with JSR 181 spec
> ---------------------------------------------------------
>
> Key: BEEHIVE-746
> URL: http://issues.apache.org/jira/browse/BEEHIVE-746
> Project: Beehive
> Type: Bug
> Components: Web Services (181)
> Versions: V1Beta
> Environment: Beehive SVN 170442
> Reporter: Jeremiah Johnson
> Assignee: daryoush mehrtash
> Fix For: V1
> Attachments: BEEHIVE-746.tar
>
> There is an example in the JSR 181 spec in section 5.4.1.3 and another in
> section 9.1.1 showing an annotated Web service and the expected resulting
> WSDL. In both cases, a specific message element represents the header field
> and a specific message element represents the other parameters. The WSM
> implementation takes a different route and maps all parameters, header or
> body, into the header message entry in the WSDL. Is that clear? :)
> Here is the WSM version of the binding operation from the 5.4.1.3 example:
> <wsdl:operation name="SecurePing">
> <wsdlsoap:operation soapAction=""/>
> <wsdl:input name="SecurePingRequest">
> <wsdlsoap:body namespace="http://www.openuri.org/jsr181/WebParamExample";
> parts="Ping" use="literal"/>
> <wsdlsoap:header message="impl:SecurePingRequest"
> namespace="http://www.openuri.org/jsr181/WebParamExample"; part="SecHeader"
> use="literal"/>
> </wsdl:input>
> </wsdl:operation>
> And then the message element:
> <wsdl:message name="SecurePingRequest">
> <wsdl:part name="SecHeader" type="impl:SecurityHeader"/>
> <wsdl:part name="Ping" type="impl:PingDocument"/>
> </wsdl:message>
> Here is the spec version of the binding operation:
> <operation name="SecurePing">
> <soap:operation soapAction="http://openuri.org/SecurePing"/>
> <input>
> <soap:body parts="Ping" use="literal"/>
> <soap:header message="SecurePingHeaders" part="SecHeader"use="literal"/>
> </input>
> </operation>
> And the message elements:
> <message name="SecurePing">
> <part name="Ping" type="tns:Ping"/>
> </message>
> <message name="SecurePingHeaders">
> <part name="SecHeader" element="tns:SecurityHeader"/>
> </message>
> I get the impression that the non-spec route was explicitly chosen, so the
> reasoning must be documented somewhere so that it may be validated;
> otherwise, the handling of headers needs to be changed.
> Here is the wording from the spec about WebParam.header (section 7.2):
> Parameters annotated with the @WebParam.header attribute map to SOAP headers
> instead of elements in the SOAP body. Header parameters may appear as parts
> in the operation's input message, output message, or both depending on the
> value of the @WebParam.mode attribute. Header parameters are included as
> soap:header elements in the appropriate wsdl:input and wsdl:output sections
> of the binding operation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
