On 10/02/2012 15:27, Nigel Deakin wrote:
> Dear Expert Group,
>
> This is a second request for comments on the JMS 2.0 Early Draft. It's a bit quiet out there!
>
> I'd like expert group members to give an indication of whether this draft is ready for review by the community. You're
> not being asked to state that there are no issues, merely whether you think it is good enough for members of the
> community to review in detail.
>
In the course of working on the Early Draft a number of issues have come to mind, or have been brought to my attention.
We don't necessarily need to resolve all these issues before the early draft. For the "major issues" below it might be
better if we left things as they are and asked for comments. The the "minor issues" below are more straightforward and I
am tempted to try to address them before the early draft.
Comments welcome...
MAJOR ISSUES
============
* Simplified API: How should message consumers be represented?
--------------------------------------------------------------
I'm not sure we've got the API to consume messages in the simplified API quite right.
Irrespective of what the current proposals say, I think we need to decide whether the simplified API should allow
applications to create multiple consumers on the same session (messaging context), as the standard API does, or whether
it should be more restrictive in order to allow the API to be simple.
If we decide that the simplified API should allow applications to create multiple consumers on the same session then do
these need to be represented as separate consumer objects, or can this be achieved simply using methods on
MessagingContext itself?
* Injecting a MessagingContext
------------------------------
Do we need to define what the lifecycle (scope) of the underlying MessagingContext is? If so, how should this be specified?
* Batch message delivery
------------------------
I'd like to be able to describe better the benefits of this feature.
I'm a bit concerned that supporting the new BatchMessageListener interface has required quite a lot of new methods (two
new methods on MessageConsumer and five on MessagingContext). It is also a bit confusing to have to explain how
setMessageListener and setBatchBatchListener inter-relate.
It has been suggested to me that an alternative might be to invent a new message type, a BatchMessage, which would
contain a ordered collection of normal Message objects. This would allow batches of messages to be delivered to a normal
MessageListener and so remove the need for BatchMessageListener. It would also allow batch delivery using the sync
receive() methods.
What do people think?
* Send payload/receive payload messages
---------------------------------------
The simplified API proposes new methods to send a message payload directly, with the JMS provider wrapping it in an
appropriate JMS message. It also proposes two messages to synchronously receive a message payload directly, with the JMS
provider automatically extracting it from the JMS message.
These proposals currently cover String (TextMessage) and Serializable (ObjectMessage) payloads only.
I'd be particular interested in comments on the API proposed for this, and suggestions as to what the API might look
like for other payload types.
MINOR ISSUES
============
* Specifying user and password for an injected MessagingContext
---------------------------------------------------------------
I've missed out any way to set the user and password that are used when creating the MessagingContext. My immediate
thought is to add a new annotation JMSCredentials:
@Inject
@JMSCredentials(user,password)
private MessagingContext context;
* MessagingContext: setClientID(String clientID)
------------------------------------------------
It has been pointed out that the above method would attempt to set clientID on a connection that has already been used
to create a session. This would violate section 4.3.2 of the spec which states "If a client explicitly does the set it
must do this immediately after creating the connection and before any other action on the connection is taken."
We should clarify the spec to make it clear that calling setClientID on a newly-created MessagingContext is permitted
To implement this, the MessagingContext implemention would either need to set clientId using a private API or it would
need to create the session lazily.
* MessagingContext: automatically starting a connection
-------------------------------------------------------
The current proposal is that the connection's start method will be called automatically when setMessageListener,
setBatchMessageListener (for async) or createSyncMessageConsumer (for sync) are called on the MessageContext object.
It has been pointed out that there are sometimes good reasons for wanting to defer starting a connection until a later
time, such to give time for an asynchronous consumer to be fully initialised. Section 4.3.3 already discusses this
possibility.
I was wondering whether we should cater for this by allowing the application should disable the "auto-start"
functionality. We could leave autostarting as the default behaviour, but allow it to be switched off:
messagingContext.autoStart(false)
You'd need to call this before calling setMessageListener, setBatchMessageListener (for async) or
createSyncMessageConsumer (for sync))
Where the MessagingCOntext was injected, we could add a new annotation
@Inject
@JMSAutoStart(false)
MessagingContext context;