Announcement Announcement Module
No announcement yet.
WS-Addressing Required Headers Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • WS-Addressing Required Headers


    I'm using Spring WS 1.5.5 together with the SimpleActionEndpointMapping, but getting wsa:MessageAddressingHeaderRequired errors from the server when I don't expect them.

    As I understand it, the only required WS-Addressing header is wsa:Action, but Spring-WS is complaining if I don't specify either a wsa:To or wsa:MessageID header. According to the WS-Addressing standard(s) it seems like both the latter headers should be optional.

    I had a look at the source code for essingProperties, and the hasRequiredProperties() method would appear to confirm the observed behaviour; however it only insists on a MessageID if either ReplyTo or FaultTo have been specified. As I'm not sending either of those I wonder if the stack has inserted a default "anonymous endpoint" value into one or both and that is triggering the error.

    Am I missing something, or is the implementation a little too constrained?

    Many thanks


  • #2
    This looks like a bug. Could you please file a JIRA at WE might be able to fix is for 1.5.6, due any day now.



    • #3
      Hi Arjen

      Bug duly filed:

      Many thanks,



      • #4

        Is it known if the bug fixed by the JIRA incident SWS-465, is also present in " otationActionEndpointMapping"

        I'm suffering 100% similar issue with that endpoint. I'm using soapUI to quickly test my endpoint, and until I don't add a random messageID and a default To header, I'm always getting:

        <faultcode xmlns:wsa="">wsa:MessageAddressingHeaderRequired</faultcode>
        <faultstring xml:lang="en">A required header representing a Message Addressing Property is not present</faultstring>



        • #5
          I am also having the same issue as waterazu when using 'AnnotationActionEndpointMapping', The spring web services version is 2.1.2. and issue is present in that version. Is there a work around to accept the request only with wsa:action and not messageId. I am testing with a third party automated tool, so I don't have control over what comes into the request. Please reopen the