Nigel,
I was thinking about the simplified API with regard to the new method added
for creating connection factories. Would it be worthwhile to have a
utility method .createMessagingContext(Properties p) that creates the
equivalent messaging context for the given property set (since messaging
context can be created with no arguments from a connection factory).
John
On Fri, Mar 30, 2012 at 11:31 AM, Nigel Deakin <nigel.deakin_at_oracle.com>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<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
>>
>