This is a response to Rüdiger's comments on Reza's comments...
On 17/02/2012 16:06, Rüdiger zu Dohna wrote:
> 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.
>
> [Rüdiger] 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 ;-)
Java EE allows multiple consumers on the same session, though they can only be used for synchronous receive.
But I note the general remark from both of you that multiple consumers on the same session is an advanced feature and
switching back to the non-simplified API is reasonable.
>>> * 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).
>
> [Rüdiger] 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?
We have to say *something* because we don't want the application to think that the instance variable holding the
MessagingContext will correspond to the same session for the entire life of the owning bean (because that would have
implications for message ordering). I'm still looking for the right form of words here and am open to suggestions.
>>> * 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 :-|
Irrespective of what we do with MDBs, we need an API that can be used from Java SE.
I'm happy to have a discussion of MDB improvements (after the Early Draft).
Another possible Java EE approach to batch delivery might be to allow onMessage() to be called multiple times in a
single JTA transaction. I think a few JMS providers offer this already.
>
>>> * 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.
>
> [Rüdiger] Methods already exist to *create* text and (serializable) object messages,
> and I think we should expand those to bytes and map messages.
Good idea. I've logged this as
http://java.net/jira/browse/JMS_SPEC-79
> [Rüdiger] 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.).
Yes, you would not use these methods if you wanted to set message properties.
MessagingContext has methods setTimeToLive, setDeliveryMode and setPriority which can be used to set these options, or
we could add methods (admittedly we'd need one for each supported message type) to allow these to be specified when the
message was sent.
I suppose the question is whether these methods would sufficiently useful to enough users to make it worth adding them.
>
>>> * 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.
We don't have any proposals to do this currently, but I think the general issue of user authentication in Java EE is
something we should come back to. I've made a note.
(Other comments snipped).
Nigel