Bug 1080321 - wsp:Optional isn't adhered to for WS-RM policy in WSDL
Summary: wsp:Optional isn't adhered to for WS-RM policy in WSDL
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web Services
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ER10
: EAP 6.3.0
Assignee: Alessio Soldano
QA Contact: Rostislav Svoboda
Russell Dickenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-25 07:35 UTC by Tadayoshi Sato
Modified: 2018-12-05 17:50 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-06 14:34:42 UTC
Type: Bug


Attachments (Terms of Use)
Reproducer (17.51 KB, application/zip)
2014-03-25 07:35 UTC, Tadayoshi Sato
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker JBWS-3777 0 Major Closed CXF-5645: wsp:Optional isn't adhered to for WS-RM policy in WSDL 2015-04-25 20:30:09 UTC

Description Tadayoshi Sato 2014-03-25 07:35:52 UTC
Created attachment 878321 [details]
Reproducer

Description of problem:
Platform BZ for https://issues.jboss.org/browse/JBWS-3777

The wsp:Optional attribute doesn't work for WS-RM in JBoss WS CXF. As far as the specs tell both WS-Addressing 1.0 and WS-RM 1.1 should support wsp:Optional, that is, if wsp:Optional is set to true on a WS-RM policy the WS-RM policy should become optional – the endpoint should allow both messages with and without WS-RM [1]. However, my experimentation showed that it actually doesn't.

Incidentally, I couldn't reproduce the same issue on a bare CXF runtime, so I believe this is purely a JBoss WS issue.

What I did is as follows (see the attached reproducer for details):

1. Configured in WSDL (greeting.wsdl) an endpoint as optionally WS-RM enabled like the following:

    <wsdl:binding name="GreetingServiceSoapBinding" type="tns:GreetingService">
        <wsp:Policy xmlns:wsp="http://www.w3.org/2006/07/ws-policy">
            <wsam:Addressing xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata"
                wsp:Optional="true" />
            <wsrmp:RMAssertion xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"
                wsp:Optional="true" />
        </wsp:Policy>
        ...

2. Sent a WS-RM unaware (= no SOAP header) SOAP request from the client but got the following SOAP Fault:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <soap:Fault>
      <faultcode>soap:Server</faultcode>
      <faultstring>WS-Addressing is required by this endpoint.</faultstring>
    </soap:Fault>
  </soap:Body>
</soap:Envelope>

[1] In WS-RM Policy 1.1 p.8:
/wsrmp:RMAssertion/@wsp:Optional="true"
Per WS-Policy, this is compact notation for two policy alternatives, one with and one without the assertion. The intuition is that the behavior indicated by the assertion is optional, or in this case, that WS-ReliableMessaging MAY be used.

How reproducible:
100%

Steps to Reproduce:
See README.md in the attached reproducer (ws-rm.zip).

Comment 1 JBoss JIRA Server 2014-05-28 06:04:27 UTC
Jim Ma <ema@redhat.com> updated the status of jira JBWS-3777 to Resolved

Comment 2 Rostislav Svoboda 2014-07-18 11:20:34 UTC
Verified on EAP 6.3.0 ER10
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <ns2:helloResponse xmlns:ns2="http://ws.samples.redhat.com/">
         <return>Hello, Rosta!</return>
      </ns2:helloResponse>
   </soap:Body>
</soap:Envelope>

EAP 6.2.0 GA
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <soap:Fault>
         <faultcode>soap:Server</faultcode>
         <faultstring>WS-Addressing is required by this endpoint.</faultstring>
      </soap:Fault>
   </soap:Body>
</soap:Envelope>

Comment 3 JBoss JIRA Server 2015-04-25 20:30:09 UTC
Alessio Soldano <asoldano@redhat.com> updated the status of jira JBWS-3777 to Closed


Note You need to log in before you can comment on or make changes to this bug.