On 2012-02-15, at 02:47, Reza Rahman wrote:
> On 2/14/2012 12:17 PM, Nigel Deakin wrote:
>> * 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.
IIRC you can only have one consumer in EE anyways... so it's only about SE. And I think that if you have requirements like that, you're probably fine to use the non-simplified API ;-)
>> * 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).
Of course the behavior has to be deterministic! And implementable! But we don't have to specify that there has to be some underlying MessagingContext, do we?
>> * 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?).
That sounds better to me, too, but that would be a change to the EJB spec :-|
>> * 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.
Methods already exist to *create* text and (serializable) object messages, and I think we should expand those to bytes and map messages. But I think the direct *send* methods just add a lot of weight, but not such a huge difference; only one line is saved and a lot of functionality would be missing (setting properties, delivery options, etc.).
>> * 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.
Okay, as long as it can be overwritten by some deployment descriptor and by some configuration in the container.
>> * 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).
The JMS provider will have to decide how to implement that. The applications don't care.
>> * 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.
Hmmm... again: If you need such advanced control options, you're probably better off with the non-simplified API!