On 15/03/2012 12:35, Nigel Deakin wrote:
(see previous email for background)
> I think, therefore, that we should abandon this attempt at avoiding a separate consumer object for async delivery and
> reinstate a separate consumer object similar to that used in the standard API.
>
> Having hesitated over this for some time, the "clincher"for me was remembering what we already have a separate
> consumer object for sync delivery (so this is actually a simplification), and that this API will never be used in Java
> EE web or EJB applications anyway.
>
> I can't think of a good reason for having separate SyncMessageConsumer and AsyncMessageConsumer objects - this would
> be inconsistent with the standard API and would require twice as many createConsumer methods. We could use a standard
> MessageConsumer, but this would be inconsistent with one of the other goals of the simplified API, which is to offer
> method signatures which did not throw JMSException.
>
> I'd therefore like to propose a "simplified message consumer", used for both sync and async delivery, for use with
> MessagingContext. However I'm not sure what name to give it. Does anybody have any suggestions? Here are some ideas:
>
> MessageConsumer (but in a different package)
> MessagingContextConsumer
> ContextConsumer
>
> Please let me know your comments (and your naming suggestions).
>
> Note that I think we need to resolve this before we can finalise any new API for batch delivery.
>
> Nigel
>
I'm still trying to think of a suitable name for the simplified API's new unified consumer interface.
In addition to the ideas above I also came up with Consumer and MessageReceiver.
However my favourite idea is JMSConsumer, combined with renaming MessagingContext to be JMSContext.
This keeps the names short and avoids the word "messaging", which I think is a bit of a mouthful. I
The prefix JMS- is also consistent with the new annotations JMSAutoStart, JMSConnectionFactory, JMSSessionMode and
JMSPasswordCredential and the new class JMSRuntimeException.
The existence of JMSException in JMS 1.1 would prevent a "JMS" prefix always meaning "simplified API". However it does
act as a useful precedent for using the prefix "JMS".
I'll draft the changes in more detail. But in the meantime I'd welcome any feedback, either on the principle of changing
the simplified API to use a separate consumer object for async delivery or on the specific choice of name.
Nigel