On 08/12/2011 14:51, Nigel Deakin wrote:
>
> As you know we've had quite a few discussions on this already, and as promised I've written up a proposal. This is
> described in a pdf document at:
> http://java.net/downloads/jms-spec/Simplified%20API/JMS20SimplifiedAPIv1.pdf
> with a corresponding set of javadocs at:
> java.net/projects/jms-spec/downloads/download/Simplified%20API/jms-2.0-javadoc.jar
>
> Please take a look and make comments.
>
> Comments are welcome on anything I've written, but I should say from the outset that some aspects of the proposals are
> further advanced than others. In particular I haven't suggested how we might exploit the new API using CDI. I hope that
> the proposed API makes this easier to achieve but I hope to have a discussion about what we might do.
>
> The proposals also suggest a simple API for sending and receiving message payloads directly but I think this needs some
> more work.
A colleague sent me some comments I've paraphrased as follows, and added my own responses afterwards:
1. Comment: If a client uses the SyncMessageConsumer.receivePayload() methods to consume a message payload directly,
they can't perform client acknowledgement because they don't have a Message object on which to call acknowledge(). How
about adding a new method MessagingContext.acknowledge() to allow this? Since calling Message.acknowledge() actually
acknowledges all messages delivered by the Session this makes more sense anyway.
Nigel responds: Very good point, and I agree with the suggestion. We could also add Session.acknowledge() as well.
ideally we should remove Message.acknowledge() but we can't because we need to maintain backwards compatibility.
2. Comment: If you're going to start automatically the connection used by a MessagingContext as soon as
setMessageListener is called (as stated on p4) then calling setMessageListener a second time, perhaps for a second
destination, will break the threading restrictions on a Session. The client will need to call MessagingContext.stop(),
call MessagingContext.setMessageListener and then call MessagingContext.start().
Nigel responds: Good point. I suggest we expressly state that this is allowed. The implementation may either temporarily
stop the connection or it could implement it in a safe way. We should look out for other cases like this.
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.
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(...)?
Nigel responds: Yes, good idea.
Nigel