On 17 Jan 2012, at 09:42, Nigel Deakin wrote:
>
> Yes, the JMS 1.1 spec, section 4.4.6 "Conventions for using a session" explicitly mentions this issue. It says
>
> "...a connection must be in stopped mode to set up a session with more than one message listener. The reason is that when a connection is actively delivering messages, once the first message listener for a session has been registered, the session is now controlled by the thread of control that delivers messages to it. At this point a client thread of control cannot be used to further configure the session."
>
> This suggests that we have three options:
>
> 1. Abandon the idea of starting a connection automatically
> 2. Start a connection automatically by default but allow the application to disable this feature
> 3. Explicitly waive the threading restrictions when certain methods on MessagingContext such as setMessageListener are called, and leave it to the JMS provider to decide how to implement it.
>
> My preference is for (3), and I have amended the proposals document to state this (I haven't modified the spec document yet).
+1 for (3)
>
>>
>> 3. Comment: For Java SE applications which need to create two MessagingContext objects on the same underlying
>> Connection, instead of providing methods like Connection.createMessagingContext(), how about providing a new method
>> MessagingContext.createMessagingContext(sessionMode) which creates a second MessagingContext using the same Connection
>> as the first MessagingContext? This would remove the need for such applications to use Connection objects at all.
>>
>> Nigel responds: I think this is an excellent idea.
>
> I've now made this change to the proposed simplified API (the interfaces, the javadocs and the proposals document, The change is simple: I've removed Connection.createMessagingContext(sessionMode) and added a new method
> MessagingContext.createMessagingContext(sessionMode).
>
> I think the result is similar to a suggestion that Clebert made some time ago.
>
> I've also updated the example "Receiving a message in multiple threads (Java SE)" in the proposals document which now looks even simpler as a result of this change.
>
>>
>> 4. Comment: On P23 you observed that "If you simply want to create a durable subscriber, but not actually consume
>> messages from it, you now need to call createSyncDurableSubscriber, even if you intend to use async consumption in the
>> future (previously you just called createDurableSubscription). This works but the method name is confusing when used for
>> this purpose rather than to start sync consumption. Perhaps we need a void createDurableSubscription(…) method?"
>>
>> How about calling it simply subscribe(...), for consistency with unsubscribe(...)?
>
> I've now added a new method subscribe() to MessagingContext which creates a durable subscription but does not create a consumer on it.
>
> For all these changes, I've updated the javadocs and the proposals document. I still haven't attempted to say anything about the simplified API in the spec itself.
>
> The updated javadocs are in the usual place:
> http://java.net/projects/jms-spec/sources/repository/content/jms2.0/target/jms-2.0-javadoc.jar
>
> I have also produced a new version of the spmplified API proposals document. This is version 2:
> http://java.net/downloads/jms-spec/Simplified%20API/JMS20SimplifiedAPIv2.pdf
> There are change bars and a change log at the bottom.
>
> This is all the changes to the simplified API we have at the moment. The next step is to propose how applications can make use of CDI to inject MessagingContext objects.
>
> Nigel
>
>
>