jsr343-experts@jms-spec.java.net

[jsr343-experts] Re: (JMS_SPEC-64) Define simplified JMS API

From: Nigel Deakin <nigel.deakin_at_oracle.com>
Date: Fri, 30 Mar 2012 16:31:17 +0100

Thanks for the endorsement. I have now removed this.

Updated javadocs are here:
The "draft" Early Draft Javadocs are in the usual place:
http://java.net/projects/jms-spec/sources/repository/content/jms2.0/target/jms-2.0-javadoc.jar

No spec changes were needed.

Nigel

On 29/03/2012 12:56, Nigel Deakin wrote:
> I have spotted one further possible change that we may want to consider making to the simplified API. This is the
> "subscribe" method, for creating a durable subscription but not a consumer.
>
> context.subscribe(inboundTopic, "mysub", messageSelector, noLocal);
>
> I added this initially because the only alternative was to use createSyncConsumer to create a SyncMessageConsumer and
> immediately close it.
>
> SyncMessageConsumer consumer = context.createSyncDurableSubscriber(inboundTopic, "mysub");
> consumer.close();
>
> I thought this was particularly inappropriate because an application which subsequently intended to consume messages
> asynchronously would need to create a SyncMessageConsumer.
>
> However following the recent changes, an application which wants to create a durable subscription but not actually
> consume messages from it can do the following:
>
> JMSConsumer consumer = context.createDurableSubscriber(inboundTopic, "mysub");
> consumer.close();
>
> This is identical to how this would be done using the standard JMS 1.1 API.
>
> This suggests that perhaps we don't need
>
> void subscribe(Topic topic, String name, String messageSelector, boolean noLocal);
>
> after all. Applications have managed without it for a decade, and in any case this caters for a pretty rare use case
> anyway: in most cases, an application which created a durable subscription would want to go on and consume messages from
> it.
>
> So: is the subscribe method on JMSContext unnecessary bloat? Or is it a useful addition to the API? I'm not sure.
>
> Any views?
>
> Nigel