Following this final change. I think the "simplified API" issue (JMS_SPEC-64) is now complete. The injection of
JMSContext objects is still not fully resolved, but this is a separate JIRA issue (JMS_SPEC-70).
John A suggested today that we add an API method to ConnectionFactoryCreator to create a JMSContext. I responded to that
earlier (to disagree) but that discussion can continue as part of JMS_SPEC-89 (Define standard API to create and
configure a ConnectionFactory in Java SE applications and by a Java EE container).
I therefore propose to change the tag for JMS_SPEC-64 to "pd20-added" to record that it is finished (and has been added
to the next draft, the public draft) and therefore disappears off our "todo" list.
Nigel
On 30/03/2012 16:31, Nigel Deakin wrote:
> 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