Comments in-line:
On 2/14/2012 12:17 PM, Nigel Deakin wrote:
> 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?
I vote for adding the restriction that you can only have one consumer
and just having consume() method(s) on MessagingContext. For most uses
in Java EE, this is just fine. If there is a way to have multiple
underlying consumers without complicating the API, that would be fine too.
>
> * Injecting a MessagingContext
> ------------------------------
>
> Do we need to define what the lifecycle (scope) of the underlying
> MessagingContext is? If so, how should this be specified?
I definitely think scope needs to be deterministic. Otherwise, you wind
up with non-portable applications and a lot of developer confusion. In
the worst case, you can wind up with implementations that clearly cannot
scale yet are completely standards compliant! In terms of describing the
life-cycle, I would take JPA's lead. It clearly describes what the
persistence context life-cycle is without much implementation details
(such as specifically mentioning CDI Dependent, Request, etc scope).
Indeed, you can implement things even without needing a standardized
@TransactionScope simply by using the raw transaction
manager/thread-local API if you wanted to (the way most JPA proxy
implementations are likely done today and certainly Spring data API
proxies).
>
> * 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?
I am not entirely convinced about this feature and do think there might
be better ways to do this. One example would be simply having a
setBatchSize method and having modernized, POJO-oriented MDBs that can
handle both single, scalar messages and batches of messages (may the
same applies to the MessageListener interface?).
>
> * 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.
The API looks fine to me. As to expanding it, I would say
BytesMessage->byte[] and MapMessage->java.util.Map.
>
>
>
> 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;
Looks fine.
>
>
> * 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.
Sounds good. Spring gets around such problems by creating/closing
sessions on each operation (not the right design IMO).
>
> * 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;
Looks good.
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1913 / Virus Database: 2112/4808 - Release Date: 02/13/12
>
>