Section 8.7 of the JMS 2.0 spec has a malformed sentence

[glassfishrobot]

There is a confusing/malformed sentence in section 8.7 of the JMS 2.0 spec (also present in section 4.5.2 of 1.1 spec). The sentence is "Well behaved listeners should catch such exceptions and attempt to divert messages causing them to some form of application-specific 'unprocessable message' destination."

Is this trying to say ".. and attempt to divert messages to some form of application-specific ... ? In other words I feel like the words "causing them" should be removed from this sentence. In any case, it needs to be reworded somehow to make the meaning clear, in my opinion.

=== Larger quote:

8.7. Receiving messages asynchronously ...

It is possible for a listener to throw a RuntimeException; however, this is considered a client programming error. Well behaved listeners should catch such exceptions and attempt to divert messages causing them to some form of application-specific 'unprocessable message' destination.

Thanks! John Lindwall

Environment

N/A

Affected Versions

[1.1, 2.0]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/jms-spec/issues/137
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: Unassigned

[glassfishrobot]

@glassfishrobot Commented Reported by jlindwall

[glassfishrobot]

@glassfishrobot Commented @nigeldeakin said: The words "causing them" are used to suggest that the reason the listener might want to throw a RuntimeException is because there is something wrong (in application terms) with a message which prevents the message listener processing it, such as it containing invalid data.

That's why there is a suggestion that the listener should catch such exceptions and divert the "bad" message in question to to a dead message queue (DMQ) of some kind. The listener would continue to process the "good" messages as normal but would divert "bad" messages to the DMQ.

Note that the person developing the listener is free to ignore this advice and throw a RuntimeExceoption anyway. JMS provider will then behave as defined in this section.

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA JMS_SPEC-137