You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by "Jeremiah Johnson (JIRA)" <be...@incubator.apache.org> on 2005/05/17 11:53:32 UTC
[jira] Created: (BEEHIVE-746) WSDL generated for headers inconsistent with JSR 181 spec
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
Assigned to: daryoush mehrtash
Fix For: V1
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
[jira] Closed: (BEEHIVE-746) WSDL generated for headers inconsistent with JSR 181 spec
Posted by "daryoush mehrtash (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-746?page=all ]
daryoush mehrtash closed BEEHIVE-746:
-------------------------------------
Resolution: Fixed
I have talked to brian zotter, the spec lead, on this issue. He thinks our implementation is also valid and he will update the spec to reflect it.
> 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
[jira] Updated: (BEEHIVE-746) WSDL generated for headers inconsistent with JSR 181 spec
Posted by "Jeremiah Johnson (JIRA)" <be...@incubator.apache.org>.
[ 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