jms-spec
  1. jms-spec
  2. JMS_SPEC-125

Define whether a JMS provider should call reset after sending a BytesMessage asynchronously

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: JMS 2.0 rev A
    • Labels:
      None

      Description

      This issue concerns the behaviour of the JMS provider when it sends a BytesMessage.

      The spec is not clear on what state the body of a BytesMessage is left in after it has been sent. We're talking about the message object in the sending program, not in the receiving program.

      A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

      There are three possibilities:

      1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call reset.

      2. The JMS provider leaves the BytesMessage in read-only with the stream positioned at the start. To achieve this the send method would need to call reset before returning.

      3. Leave the behaviour undefined.

      This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to send returns. In the async case the issue is what state the message is in when the CompletionListener callback is performed. Let's consider these separately.

      Asynchronous send

      Option 1 (leave the body in write-only mode with the stream positioned at the end):

      • It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call reset, but that would position the stream back at the start.

      Option 2 (leave the body in read-only mode with the stream positioned at the start).

      • This is the current de facto spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a BytesMessage asynchronously and which attempts to read the body of the message object passed to the CompletionListener. without calling reset. All existing JMS 2.0 providers will have passed this test.
      • There is also a clear use case for this option, since It is expected that a CompletionListener callback method may want to read the message in order to identify the message that was successfully sent.

      Option 3 (leave the behaviour undefined).

      • This is undesirable because the only things a portable application application could do would be to call reset and read the message, or call clearBody to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

      Proposal: It is therefore proposed to update the JMS 2.0 specification to require the behaviour described in option 2: when a BytesMessage is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the CompletionListener. To achieve this the send method would need to call reset before returning.

      Synchronous send

      JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

      In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a BytesMessage after it has been sent.

      Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.

      Proposal It is proposed to update the JMS 2.0 specification to recommend, but not require, that the provider should call reset before the send() returns, and to add a warning that portable applications must not make assumptions about what state the message is in.

        Issue Links

          Activity

          Nigel Deakin created issue -
          Nigel Deakin made changes -
          Field Original Value New Value
          Summary Define whether a JMS provider should call reset after sending a BytesMessage Define whether a JMS provider should call reset after sending a BytesMessage asynchronously
          Nigel Deakin made changes -
          Tags jms20-bug jms20-errata
          Nigel Deakin made changes -
          Description This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. I'm talking about the message object in the _sending_ program, not in the receiving program. There are three possibilities:

          1. The JMS provider leaves the body in the same state as it was before the call to the send method. That is, it is in write-only mode with the stream positioned at the end. That allows the application at append data to the message after sending.

          2. The JMS provider calls reset(). This leaves the {{BytesMessage}} in read-only with the stream positioned at the start.

          3. Leave the behaviour undefined.

          I would rather not adopt (3) if we can avoid it. The state that the message body is in affects the portability of applications between JMS providers so the required behaviour should be defined if possible.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to send() returns. In the async case the message is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Asynchronous send is a new feature, so although the JMS 2.0 spec is not specific about this, it's not too late to add define the required behaviour more specifically.

          I think with an asynchronous send there is a clear benefit in adopting (2). It is possible that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent. After all, what the point is of passing a message to {{onCompletion()}} if its body is not readable?

          Another reason for adopting (2) is that I don't think that it is practically possible to adopt (1). This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message, which means it will need to call reset() before doing so. That would leave the message in read-only mode.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. I therefore think it is probably too late to define more specific behaviour.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. I'm talking about the message object in the _sending_ program, not in the receiving program. There are three possibilities:

          1. The JMS provider leaves the body in the same state as it was before the call to the send method. That is, it is in write-only mode with the stream positioned at the end. That allows the application at append data to the message after sending.

          2. The JMS provider calls reset(). This leaves the {{BytesMessage}} in read-only with the stream positioned at the start.

          3. Leave the behaviour undefined.

          I would rather not adopt (3) if we can avoid it. The state that the message body is in affects the portability of applications between JMS providers so the required behaviour should be defined if possible.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to send() returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Asynchronous send is a new feature, so although the JMS 2.0 spec is not specific about this, it's not too late to add define the required behaviour more specifically.

          I think with an asynchronous send there is a clear benefit in adopting (2). It is possible that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent. After all, what the point is of passing a message to {{onCompletion()}} if its body is not readable?

          Another reason for adopting (2) is that I don't think that it is practically possible to adopt (1). This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message, which means it will need to call reset() before doing so. That would leave the message in read-only mode.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. I therefore think it is probably too late to define more specific behaviour.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          Nigel Deakin made changes -
          Description This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. I'm talking about the message object in the _sending_ program, not in the receiving program. There are three possibilities:

          1. The JMS provider leaves the body in the same state as it was before the call to the send method. That is, it is in write-only mode with the stream positioned at the end. That allows the application at append data to the message after sending.

          2. The JMS provider calls reset(). This leaves the {{BytesMessage}} in read-only with the stream positioned at the start.

          3. Leave the behaviour undefined.

          I would rather not adopt (3) if we can avoid it. The state that the message body is in affects the portability of applications between JMS providers so the required behaviour should be defined if possible.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to send() returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Asynchronous send is a new feature, so although the JMS 2.0 spec is not specific about this, it's not too late to add define the required behaviour more specifically.

          I think with an asynchronous send there is a clear benefit in adopting (2). It is possible that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent. After all, what the point is of passing a message to {{onCompletion()}} if its body is not readable?

          Another reason for adopting (2) is that I don't think that it is practically possible to adopt (1). This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message, which means it will need to call reset() before doing so. That would leave the message in read-only mode.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. I therefore think it is probably too late to define more specific behaviour.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. I'm talking about the message object in the _sending_ program, not in the receiving program. There are three possibilities:

          1. The JMS provider leaves the body in the same state as it was before the call to the send method. That is, it is in write-only mode with the stream positioned at the end. That allows the application at append data to the message after sending.

          2. The JMS provider calls {{reset()}}. This leaves the {{BytesMessage}} in read-only with the stream positioned at the start.

          3. Leave the behaviour undefined.

          I would rather not adopt (3) if we can avoid it. The state that the message body is in affects the portability of applications between JMS providers so the required behaviour should be defined if possible.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Asynchronous send is a new feature, so although the JMS 2.0 spec is not specific about this, it's not too late to add define the required behaviour more specifically.

          I think with an asynchronous send there is a clear benefit in adopting (2). It is possible that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent. After all, what the point is of passing a message to {{onCompletion()}} if its body is not readable?

          Another reason for adopting (2) is that I don't think that it is practically possible to adopt (1). This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message, which means it will need to call reset() before doing so. That would leave the message in read-only mode.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. I therefore think it is probably too late to define more specific behaviour.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          Nigel Deakin made changes -
          Description This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. I'm talking about the message object in the _sending_ program, not in the receiving program. There are three possibilities:

          1. The JMS provider leaves the body in the same state as it was before the call to the send method. That is, it is in write-only mode with the stream positioned at the end. That allows the application at append data to the message after sending.

          2. The JMS provider calls {{reset()}}. This leaves the {{BytesMessage}} in read-only with the stream positioned at the start.

          3. Leave the behaviour undefined.

          I would rather not adopt (3) if we can avoid it. The state that the message body is in affects the portability of applications between JMS providers so the required behaviour should be defined if possible.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Asynchronous send is a new feature, so although the JMS 2.0 spec is not specific about this, it's not too late to add define the required behaviour more specifically.

          I think with an asynchronous send there is a clear benefit in adopting (2). It is possible that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent. After all, what the point is of passing a message to {{onCompletion()}} if its body is not readable?

          Another reason for adopting (2) is that I don't think that it is practically possible to adopt (1). This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message, which means it will need to call reset() before doing so. That would leave the message in read-only mode.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. I therefore think it is probably too late to define more specific behaviour.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. I'm talking about the message object in the _sending_ program, not in the receiving program. There are three possibilities:

          1. The JMS provider leaves the body in the same state as it was before the call to the send method. That is, it is in write-only mode with the stream positioned at the end. That allows the application at append data to the message after sending.

          2. The JMS provider calls {{reset()}}. This leaves the {{BytesMessage}} in read-only with the stream positioned at the start.

          3. Leave the behaviour undefined.

          I would rather not adopt (3) if we can avoid it. The state that the message body is in affects the portability of applications between JMS providers so the required behaviour should be defined if possible.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Asynchronous send is a new feature, so although the JMS 2.0 spec is not specific about this, it's not too late to define the required behaviour more specifically.

          I think with an asynchronous send there is a clear benefit in adopting (2). It is possible that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent. After all, what the point is of passing a message to {{onCompletion()}} if its body is not readable?

          Another reason for adopting (2) is that I don't think that it is practically possible to adopt (1). This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message, which means it will need to call reset() before doing so. That would leave the message in read-only mode.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. I therefore think it is probably too late to define more specific behaviour.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          Nigel Deakin made changes -
          Description This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. I'm talking about the message object in the _sending_ program, not in the receiving program. There are three possibilities:

          1. The JMS provider leaves the body in the same state as it was before the call to the send method. That is, it is in write-only mode with the stream positioned at the end. That allows the application at append data to the message after sending.

          2. The JMS provider calls {{reset()}}. This leaves the {{BytesMessage}} in read-only with the stream positioned at the start.

          3. Leave the behaviour undefined.

          I would rather not adopt (3) if we can avoid it. The state that the message body is in affects the portability of applications between JMS providers so the required behaviour should be defined if possible.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Asynchronous send is a new feature, so although the JMS 2.0 spec is not specific about this, it's not too late to define the required behaviour more specifically.

          I think with an asynchronous send there is a clear benefit in adopting (2). It is possible that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent. After all, what the point is of passing a message to {{onCompletion()}} if its body is not readable?

          Another reason for adopting (2) is that I don't think that it is practically possible to adopt (1). This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message, which means it will need to call reset() before doing so. That would leave the message in read-only mode.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. I therefore think it is probably too late to define more specific behaviour.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1: It is not practically possible for a JMS provider to implement this. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message, which means it will need to call reset() before doing so. That would leave the message in read-only mode.

          Option 2. This is the current de facto spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3. This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          There is therefore a good case for updating the JMS 2.0 specification to state that when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          Nigel Deakin made changes -
          Description This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1: It is not practically possible for a JMS provider to implement this. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message, which means it will need to call reset() before doing so. That would leave the message in read-only mode.

          Option 2. This is the current de facto spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3. This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          There is therefore a good case for updating the JMS 2.0 specification to state that when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1: It is not practically possible for a JMS provider to implement this (implement this correctly). This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message, which means it will need to call reset() before doing so. That would leave the message in read-only mode.

          Option 2. This is the current de facto spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3. This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          There is therefore a good case for updating the JMS 2.0 specification to state that when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          Nigel Deakin made changes -
          Description This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1: It is not practically possible for a JMS provider to implement this (implement this correctly). This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message, which means it will need to call reset() before doing so. That would leave the message in read-only mode.

          Option 2. This is the current de facto spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3. This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          There is therefore a good case for updating the JMS 2.0 specification to state that when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1: It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message, which means it will need to call reset() before doing so. That would leave the message in read-only mode.

          Option 2. This is the current de facto spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3. This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          There is therefore a good case for updating the JMS 2.0 specification to state that when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          Nigel Deakin made changes -
          Description This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1: It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message, which means it will need to call reset() before doing so. That would leave the message in read-only mode.

          Option 2. This is the current de facto spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3. This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          There is therefore a good case for updating the JMS 2.0 specification to state that when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1: It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2. This is the current de facto spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3. This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          There is therefore a good case for updating the JMS 2.0 specification to state that when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          Nigel Deakin made changes -
          Description This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1: It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2. This is the current de facto spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3. This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          There is therefore a good case for updating the JMS 2.0 specification to state that when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end): It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start). This is the current de facto spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3. This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          There is therefore a good case for updating the JMS 2.0 specification to state that when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          Nigel Deakin made changes -
          Description This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end): It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start). This is the current de facto spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3. This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          There is therefore a good case for updating the JMS 2.0 specification to state that when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          _This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end): It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start). This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3. This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          There is therefore a good case for updating the JMS 2.0 specification to state that when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          Nigel Deakin made changes -
          Description _This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end): It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start). This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3. This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          There is therefore a good case for updating the JMS 2.0 specification to state that when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          _This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end): It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start). This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3 (leave the behaviour undefined). This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          There is therefore a good case for updating the JMS 2.0 specification to state that when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          Nigel Deakin made changes -
          Description _This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end): It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start). This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3 (leave the behaviour undefined). This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          There is therefore a good case for updating the JMS 2.0 specification to state that when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          _This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end): It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start). This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3 (leave the behaviour undefined). This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          There is therefore a good case for updating the JMS 2.0 specification to require the behaviour described in option 2: when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          Nigel Deakin made changes -
          Description _This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end): It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start). This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3 (leave the behaviour undefined). This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          There is therefore a good case for updating the JMS 2.0 specification to require the behaviour described in option 2: when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          _This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end): It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start). This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3 (leave the behaviour undefined). This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          *Proposal*: It is therefore proposed to update the JMS 2.0 specification to require the behaviour described in option 2: when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          Nigel Deakin made changes -
          Description _This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end): It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start). This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3 (leave the behaviour undefined). This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          *Proposal*: It is therefore proposed to update the JMS 2.0 specification to require the behaviour described in option 2: when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.



          _This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end): It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start). This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3 (leave the behaviour undefined). This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          *Proposal*: It is therefore proposed to update the JMS 2.0 specification to require the behaviour described in option 2: when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.

          *Proposal* It is proposed to updater the JMS 2.0 specification to recommend, but not require, that the provider should call reset before the send() returns, and to add a warning that portable applications must not make assumptions about what state the message is in.



          Nigel Deakin made changes -
          Description _This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end): It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start). This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3 (leave the behaviour undefined). This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          *Proposal*: It is therefore proposed to update the JMS 2.0 specification to require the behaviour described in option 2: when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.

          *Proposal* It is proposed to updater the JMS 2.0 specification to recommend, but not require, that the provider should call reset before the send() returns, and to add a warning that portable applications must not make assumptions about what state the message is in.



          _This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end): It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start). This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3 (leave the behaviour undefined). This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          *Proposal*: It is therefore proposed to update the JMS 2.0 specification to require the behaviour described in option 2: when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.

          *Proposal* It is proposed to update the JMS 2.0 specification to recommend, but not require, that the provider should call reset before the send() returns, and to add a warning that portable applications must not make assumptions about what state the message is in.



          Nigel Deakin made changes -
          Description _This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end): It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start). This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3 (leave the behaviour undefined). This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          *Proposal*: It is therefore proposed to update the JMS 2.0 specification to require the behaviour described in option 2: when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.

          *Proposal* It is proposed to update the JMS 2.0 specification to recommend, but not require, that the provider should call reset before the send() returns, and to add a warning that portable applications must not make assumptions about what state the message is in.



          This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end): It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start). This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3 (leave the behaviour undefined). This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          *Proposal*: It is therefore proposed to update the JMS 2.0 specification to require the behaviour described in option 2: when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.

          *Proposal* It is proposed to update the JMS 2.0 specification to recommend, but not require, that the provider should call reset before the send() returns, and to add a warning that portable applications must not make assumptions about what state the message is in.



          Nigel Deakin made changes -
          Description This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end): It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start). This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test. There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3 (leave the behaviour undefined). This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          *Proposal*: It is therefore proposed to update the JMS 2.0 specification to require the behaviour described in option 2: when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.

          *Proposal* It is proposed to update the JMS 2.0 specification to recommend, but not require, that the provider should call reset before the send() returns, and to add a warning that portable applications must not make assumptions about what state the message is in.



          This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end):
          \\ \\
          * It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start).
          \\ \\
          * This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test.

          * There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          * This is also consistent with the state of a message that has been received. Section 3.11.2 of the JMS 2.0 specification (which applies to all message types) states that "When a message is received, its body is read only".

          Option 3 (leave the behaviour undefined).
          \\ \\
          * This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          *Proposal*: It is therefore proposed to update the JMS 2.0 specification to require the behaviour described in option 2: when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.

          *Proposal* It is proposed to update the JMS 2.0 specification to recommend, but not require, that the provider should call reset before the send() returns, and to add a warning that portable applications must not make assumptions about what state the message is in.



          Nigel Deakin made changes -
          Description This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end):
          \\ \\
          * It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start).
          \\ \\
          * This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test.

          * There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          * This is also consistent with the state of a message that has been received. Section 3.11.2 of the JMS 2.0 specification (which applies to all message types) states that "When a message is received, its body is read only".

          Option 3 (leave the behaviour undefined).
          \\ \\
          * This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          *Proposal*: It is therefore proposed to update the JMS 2.0 specification to require the behaviour described in option 2: when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.

          *Proposal* It is proposed to update the JMS 2.0 specification to recommend, but not require, that the provider should call reset before the send() returns, and to add a warning that portable applications must not make assumptions about what state the message is in.



          This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end):
          \\
          * It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start).
          \\
          * This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test.

          * There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          * This is also consistent with the state of a message that has been received. Section 3.11.2 of the JMS 2.0 specification (which applies to all message types) states that "When a message is received, its body is read only".

          Option 3 (leave the behaviour undefined).
          \\
          * This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          *Proposal*: It is therefore proposed to update the JMS 2.0 specification to require the behaviour described in option 2: when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.

          *Proposal* It is proposed to update the JMS 2.0 specification to recommend, but not require, that the provider should call reset before the send() returns, and to add a warning that portable applications must not make assumptions about what state the message is in.



          Nigel Deakin made changes -
          Description This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end):
          \\
          * It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start).
          \\
          * This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test.

          * There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          * This is also consistent with the state of a message that has been received. Section 3.11.2 of the JMS 2.0 specification (which applies to all message types) states that "When a message is received, its body is read only".

          Option 3 (leave the behaviour undefined).
          \\
          * This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          *Proposal*: It is therefore proposed to update the JMS 2.0 specification to require the behaviour described in option 2: when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.

          *Proposal* It is proposed to update the JMS 2.0 specification to recommend, but not require, that the provider should call reset before the send() returns, and to add a warning that portable applications must not make assumptions about what state the message is in.



          This issue concerns the behaviour of the JMS provider when it sends a {{BytesMessage}}.

          The spec is not clear on what state the body of a {{BytesMessage}} is left in after it has been sent. We're talking about the message object in the _sending_ program, not in the receiving program.

          A JMS 2.0 vendor has asked for the behaviour to be clarified for async send. However this issue will discuss the behaviour for both async and sync send.

          There are three possibilities:

          1. The JMS provider leaves the body in write-only mode with the stream positioned at the end. That would allow the application to send a message, append additional data to the message body, and send it a second time. An application which wanted to read the message body would have to call {{reset}}.

          2. The JMS provider leaves the {{BytesMessage}} in read-only with the stream positioned at the start. To achieve this the {{send}} method would need to call {{reset}} before returning.

          3. Leave the behaviour undefined.

          This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to {{send}} returns. In the async case the issue is what state the message is in when the {{CompletionListener}} callback is performed. Let's consider these separately.

          *Asynchronous send*

          Option 1 (leave the body in write-only mode with the stream positioned at the end):
          \\
          * It is not practically possible for a JMS provider to implement this correctly. This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (as required by JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message. After it has done so the message would be in read-only mode, with the stream positioned at the end. The only way to change the message to write-only mode would be to call {{reset}}, but that would position the stream back at the start.

          Option 2 (leave the body in read-only mode with the stream positioned at the start).
          \\
          * This is the current _de facto_ spec requirement for async send. This is because there is a JMS 2.0 TCK test which sends a {{BytesMessage}} asynchronously and which attempts to read the body of the message object passed to the {{CompletionListener}}. without calling {{reset}}. All existing JMS 2.0 providers will have passed this test.

          * There is also a clear use case for this option, since It is expected that a {{CompletionListener}} callback method may want to read the message in order to identify the message that was successfully sent.

          Option 3 (leave the behaviour undefined).
          \\
          * This is undesirable because the only things a portable application application could do would be to call {{reset}} and read the message, or call {{clearBody}} to clear it and re-write it from scratch. If a JMS provider left the body in write-only mode with the stream positioned at the end, and the application took advantage of this to append to the body, then the application would not be portable.

          *Proposal*: It is therefore proposed to update the JMS 2.0 specification to require the behaviour described in option 2: when a {{BytesMessage}} is sent asynchronously, the message object that was sent must be set to be read-only with the stream positioned at the start prior to calling the {{CompletionListener}}. To achieve this the {{send}} method would need to call {{reset}} before returning.

          *Synchronous send*

          JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. It is therefore probably too late to define more specific behaviour, especially as this has not been reported as an issue by users or vendors.

          In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a {{BytesMessage}} after it has been sent.

          Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.

          *Proposal* It is proposed to update the JMS 2.0 specification to recommend, but not require, that the provider should call reset before the send() returns, and to add a warning that portable applications must not make assumptions about what state the message is in.



          Nigel Deakin made changes -
          Link This issue is related to JMS_SPEC-166 [ JMS_SPEC-166 ]
          Nigel Deakin made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Assignee Nigel Deakin [ nigeldeakin ]
          Fix Version/s JMS 2.0 rev A [ 17297 ]
          Resolution Fixed [ 1 ]

            People

            • Assignee:
              Nigel Deakin
              Reporter:
              Nigel Deakin
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: