Uploaded image for project: 'CXF'
  1. CXF
  2. CXF-3151

Invalid WS-A ReplyTo constant value used by WS-RM

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.2.11
    • 2.2.12, 2.3.1, 2.4
    • WS-* Components
    • None
    • Novice

    Description

      There is an issue in the way how the current WS-RM implementation
      downgrades the WS-A namespace/constants to the 2004/08 version. I
      would like to first explain the problem and ask you which solution is
      preferred.

      CXF uses WS-A 2005/08 internally but for WS-RM, it uses the 2004/08
      version because the older WS-RM (1.0)
      requires the use of the 2004/08 version. So, it is correct to convert
      the internally used 2005/08 namespace/constants to their 2004/08
      counterparts.

      However, one problem is that the 2005/08 WS-A spec defined two constants

      http://www.w3.org/2005/08/addressing/anonymous
      http://www.w3.org/2005/08/addressing/none

      While the 2004/08 WS-A version seems to have only defined

      http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous

      and not

      http://schemas.xmlsoap.org/ws/2004/08/addressing/role/none

      The current conversion used in CXF creates this undefined value and
      this is causing some interoperability issues.
      More concretely, when the WS-A ReplyTo element is set to the none
      value and this is serialized into the above undefined 2004/08 none
      constant, it is not recognized by some systems. According to the WS-RM
      1.0, in such a case, the ReplyTo element should be omitted to convey
      this "none" value (as there is no "none" constant).

      Initially, I thought we should fix this issue by introducing a configurable property "usingNoneAddress" for the addressing configuration bean to turn on or off the serialization of the none address. However, this approach had a drawback on requiring a different default value interpretation based on the used namespace versions (i.e., false for 2004/08 and true for 2005/08) to make the test cases all work.

      Therefore, I am proposing the following approach to solve this issue.

      There is no configuration property. The serialization is determined by the addressing namespace. Under 2004/08, the none value is omitted from serialization, while under 2005/08, the none value is serialized.

      This will work for all the current tests except for the testVersioning test of MAPTest. This particular test uses the 2004/08 namespace and checks the presence of the ReplyTo header in the SOAP header, even though the header is associated with the none value and therefore it must not be present. In order to fix this test, I needed to modify the corresponding verification classes so that the presence of the ReplyTo header is not verified when the 2004/08 namespace is used.

      In summary, the changes that I suggest are as follows:

      For the runtime ws.addressing:
      org.apache.cxf.ws.addressing.soap.MAPCodec
      The ReplyTo header will not be serialized with the invalid none value. In other words, if the value is set to the none value while using the 2004/08 namespace.

      org.apache.cxf.ws.addressing.ContextUtils
      The back channel will be found even when the ReplyTo header is missing.

      For the systests ws.addressing
      org.apache.cxf.systest.ws.addressing MAPTestBase
      Its verifyHeaders method takes additionally a Boolean parameter replyToRequired to indicate whether the presence of the ReplyTo header must be verified.

      org.apache.cxf.systest.ws.addressing HeaderVerifier
      Its verify method call the above verityHeaders method with the replyToRequired parameter set based on the namespace version.

      The svn diff files of the above changes are attached.

      Regards, Aki

      Attachments

        1. svndiff.zip
          2 kB
          Akitoshi Yoshida

        Activity

          People

            ffang Freeman Yue Fang
            ay Akitoshi Yoshida
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: