jms-spec
  1. jms-spec
  2. JMS_SPEC-58

New method Message.copyMessage() to create a mutable copy of a received message

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.1
    • Fix Version/s: None
    • Labels:
      None

      Description

      javax.jms.Message is mutable when first created.
      On a TextMessage you can set for example 'the text'.You can also set properties.
      However, after receiving a message, setting a property does not work anymore before clearing the properties explicitly
      This means that if you want to re-send the same message + extra properties, you need to read them, store temporary, clear message and set them again.

      Suggestion is to foresee somekind of copy constructor, or another way of creating a new message from an existing one.
      Another way could be to let the properties be mutable.

        Activity

        Hide
        rdohna added a comment -

        I like the copy-constructor... this may also help resolve JMS_SPEC-60

        Show
        rdohna added a comment - I like the copy-constructor... this may also help resolve JMS_SPEC-60
        Hide
        Nigel Deakin added a comment -

        The reason you need to call clearProperties() before setting individual properties on a received message is given in section 3.10. "Changing the value of a received message" of the JMS 1.1 spec. This states:

        When a message is received, its header field values can be changed; however, its property entries and its body are read-only, as specified in this chapter.

        The rationale for the read-only restriction is that it gives JMS Providers more freedom in how they implement the management of received messages. For instance, they may return a message object that references property entries and body values that reside in an internal message buffer rather than being forced to make a copy.

        A consumer can modify a received message after calling either the clearBody or clearProperties method to make the body or properties writable. If the consumer modifies a received message, and the message is subsequently redelivered, the redelivered message must be the original, unmodified message (except for headers and properties modified by the JMS provider as a result of the redelivery, such as the JMSRedelivered header and the JMSXDeliveryCount property).

        I think that explanation is still valid and so the existing behaviour is justified.

        The proposal for a copy constructor is worth considering and will be considered by the expert group for inclusion in the JMS 2.0 early draft. Tagging appropriately.

        Show
        Nigel Deakin added a comment - The reason you need to call clearProperties() before setting individual properties on a received message is given in section 3.10. "Changing the value of a received message" of the JMS 1.1 spec. This states: When a message is received, its header field values can be changed; however, its property entries and its body are read-only, as specified in this chapter. The rationale for the read-only restriction is that it gives JMS Providers more freedom in how they implement the management of received messages. For instance, they may return a message object that references property entries and body values that reside in an internal message buffer rather than being forced to make a copy. A consumer can modify a received message after calling either the clearBody or clearProperties method to make the body or properties writable. If the consumer modifies a received message, and the message is subsequently redelivered, the redelivered message must be the original, unmodified message (except for headers and properties modified by the JMS provider as a result of the redelivery, such as the JMSRedelivered header and the JMSXDeliveryCount property). I think that explanation is still valid and so the existing behaviour is justified. The proposal for a copy constructor is worth considering and will be considered by the expert group for inclusion in the JMS 2.0 early draft. Tagging appropriately.
        Hide
        Nigel Deakin added a comment -

        Description of this issue changed from "Immutability Message properties" to "New method Message.copyMessage() to create a mutable copy of a received message" to better describe the proposal.

        Show
        Nigel Deakin added a comment - Description of this issue changed from "Immutability Message properties" to "New method Message.copyMessage() to create a mutable copy of a received message" to better describe the proposal.

          People

          • Assignee:
            Unassigned
            Reporter:
            koen.serneels
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: