[
https://issues.apache.org/jira/browse/CXF-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jimma updated CXF-2827:
-----------------------
Summary: JAXWS2.2: wsam:action attribute is not generated in
<wsdl:input> and <wsdl:ouput> element when the SEI method is not annotated with
@Action (was: JAXWS2.2: <wsa:action> URI is not correct for the SEI method
without @Action for input and output )
Description:
When there is no @Action annotated to SEI method , the wsa action value in wsdl
should be computed with :
---JAXWS 2.2 Spec ----
"If wsdl:inp...@wsam:Action] cannot be mapped from the above steps, then
wsam:Action
is generated using the metadata defaulting algorithm as if wsdl:inp...@name] is
not present in
WSDL."
----WSA 1.1 WSDL Binding -------
A default pattern is also defined for backwards compatibility with WSDL 1.1. In
the absence of the wsaw:Action attribute, the following pattern is used to
construct a default action for inputs and outputs. The general form of an
action IRI is as follows:
Example 4-6. Structure of defaulted wsa:Action IRI.
[target namespace][delimiter][port type name][delimiter][input|output name]
For fault messages, the general form of an action IRI is as follows:
Example 4-7. Structure of default wsa:Action IRI for faults
[target namespace][delimiter][port type name][delimiter][operation
name][delimiter]Fault[delimiter][fault name]
Example 4-9. Example WSDL without explicit wsa:Action values or explicit
message names.
<definitions targetNamespace="http://greath.example.com/2004/wsdl/resSvc"; ...>
...
<portType name="reservationInterface">
<operation name="opCheckAvailability">
<input message="tns:checkAvailability"/>
<output message="tns:checkAvailabilityResponse"/>
</operation>
</portType>
...
</definitions>
[targetNamespace] = http://greath.example.com/2004/wsdl/resSvc
[port type name] = reservationInterface
According to the rules defined in Section 2.4.5 of WSDL 1.1, if the name
attribute is absent for the input of a request response operation the default
value is the name of the operation with "Request" appended.
[input name] = opCheckAvailabilityRequest
Likewise, the output defaults to the operation name with "Response" appended.
[output name] = opCheckAvailabilityResponse
Applying the pattern above with these values we have:
input action =
http://greath.example.com/2004/wsdl/resSvc/reservationInterface/opCheckAvailabilityRequest
output action =
http://greath.example.com/2004/wsdl/resSvc/reservationInterface/opCheckAvailabilityResponse
We now generated the the name attribute value for <wsdl:input>, this will
effect the action computation :
if <[input name] = opCheckAvailability> , then input action =
http://greath.example.com/2004/wsdl/resSvc/reservationInterface/opCheckAvailability.
It's not
http://greath.example.com/2004/wsdl/resSvc/reservationInterface/opCheckAvailabilityRequest
anymore .
was:
When there is no @Action annotated to SEI method , the wsa action should be
computed with :
---JAXWS 2.2 Spec ----
"If wsdl:inp...@wsam:Action] cannot be mapped from the above steps, then
wsam:Action
is generated using the metadata defaulting algorithm as if wsdl:inp...@name] is
not present in
WSDL."
----WSA 1.1 WSDL Binding -------
A default pattern is also defined for backwards compatibility with WSDL 1.1. In
the absence of the wsaw:Action attribute, the following pattern is used to
construct a default action for inputs and outputs. The general form of an
action IRI is as follows:
Example 4-6. Structure of defaulted wsa:Action IRI.
[target namespace][delimiter][port type name][delimiter][input|output name]
For fault messages, the general form of an action IRI is as follows:
Example 4-7. Structure of default wsa:Action IRI for faults
[target namespace][delimiter][port type name][delimiter][operation
name][delimiter]Fault[delimiter][fault name]
Example 4-9. Example WSDL without explicit wsa:Action values or explicit
message names.
<definitions targetNamespace="http://greath.example.com/2004/wsdl/resSvc"; ...>
...
<portType name="reservationInterface">
<operation name="opCheckAvailability">
<input message="tns:checkAvailability"/>
<output message="tns:checkAvailabilityResponse"/>
</operation>
</portType>
...
</definitions>
[targetNamespace] = http://greath.example.com/2004/wsdl/resSvc
[port type name] = reservationInterface
According to the rules defined in Section 2.4.5 of WSDL 1.1, if the name
attribute is absent for the input of a request response operation the default
value is the name of the operation with "Request" appended.
[input name] = opCheckAvailabilityRequest
Likewise, the output defaults to the operation name with "Response" appended.
[output name] = opCheckAvailabilityResponse
Applying the pattern above with these values we have:
input action =
http://greath.example.com/2004/wsdl/resSvc/reservationInterface/opCheckAvailabilityRequest
output action =
http://greath.example.com/2004/wsdl/resSvc/reservationInterface/opCheckAvailabilityResponse
We should append the "Request" to opeation name as the WSA action value.
> JAXWS2.2: wsam:action attribute is not generated in <wsdl:input> and
> <wsdl:ouput> element when the SEI method is not annotated with @Action
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CXF-2827
> URL: https://issues.apache.org/jira/browse/CXF-2827
> Project: CXF
> Issue Type: Bug
> Components: Tooling, WS-* Components
> Affects Versions: 2.2.8
> Reporter: jimma
> Assignee: jimma
> Fix For: 2.2.9
>
>
> When there is no @Action annotated to SEI method , the wsa action value in
> wsdl should be computed with :
> ---JAXWS 2.2 Spec ----
> "If wsdl:inp...@wsam:Action] cannot be mapped from the above steps, then
> wsam:Action
> is generated using the metadata defaulting algorithm as if wsdl:inp...@name]
> is not present in
> WSDL."
> ----WSA 1.1 WSDL Binding -------
> A default pattern is also defined for backwards compatibility with WSDL 1.1.
> In the absence of the wsaw:Action attribute, the following pattern is used to
> construct a default action for inputs and outputs. The general form of an
> action IRI is as follows:
> Example 4-6. Structure of defaulted wsa:Action IRI.
> [target namespace][delimiter][port type name][delimiter][input|output name]
> For fault messages, the general form of an action IRI is as follows:
> Example 4-7. Structure of default wsa:Action IRI for faults
> [target namespace][delimiter][port type name][delimiter][operation
> name][delimiter]Fault[delimiter][fault name]
> Example 4-9. Example WSDL without explicit wsa:Action values or explicit
> message names.
> <definitions targetNamespace="http://greath.example.com/2004/wsdl/resSvc"; ...>
> ...
> <portType name="reservationInterface">
> <operation name="opCheckAvailability">
> <input message="tns:checkAvailability"/>
> <output message="tns:checkAvailabilityResponse"/>
> </operation>
> </portType>
> ...
> </definitions>
>
> [targetNamespace] = http://greath.example.com/2004/wsdl/resSvc
> [port type name] = reservationInterface
> According to the rules defined in Section 2.4.5 of WSDL 1.1, if the name
> attribute is absent for the input of a request response operation the default
> value is the name of the operation with "Request" appended.
> [input name] = opCheckAvailabilityRequest
> Likewise, the output defaults to the operation name with "Response" appended.
> [output name] = opCheckAvailabilityResponse
> Applying the pattern above with these values we have:
> input action =
> http://greath.example.com/2004/wsdl/resSvc/reservationInterface/opCheckAvailabilityRequest
> output action =
> http://greath.example.com/2004/wsdl/resSvc/reservationInterface/opCheckAvailabilityResponse
> We now generated the the name attribute value for <wsdl:input>, this will
> effect the action computation :
> if <[input name] = opCheckAvailability> , then input action =
> http://greath.example.com/2004/wsdl/resSvc/reservationInterface/opCheckAvailability.
> It's not
> http://greath.example.com/2004/wsdl/resSvc/reservationInterface/opCheckAvailabilityRequest
> anymore .
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
