As promised, I've now removed references to batch delivery from the draft specification and javadocs. The issue remains
open but is not longer being considered for JMS 2.0. We can consider the issue again in a future revision of JMS.
Nigel
On 19/04/2012 16:18, Nigel Deakin wrote:
> (Correction to previous email)
>
> I've received no further comments. The results of voting are:
>
> A. We should keep the async batch message delivery feature using the BatchMessageListener API proposed in the Early Draft:
> NO votes
>
> B. We should keep the async batch message delivery feature but use the BatchMessage API proposed on 13 March:
> Nigel, Rob Davies, John Harby
>
> C. We should remove the async batch message delivery feature from JMS 2.0 and consider it again for Java EE 8.
> Reza Rahman, Rüdiger zu Dohna, and an implicit vote from John Ament.
>
> In the absence of clear support for any change (and nothing heard from the original proposer),
> I propose we abandon this feature from JMS 2.0.
>
> I will remove it from the draft specification and javadocs. We can consider the issue again in a future revision of JMS.
>
> Nigel
>>
>>
>>
>> On 16/03/2012 12:46, Nigel Deakin wrote:
>>> There have been some interesting discussions going on since last September over in the EJB EG about how MDBs could be
>>> made more general so they didn't need to implement MessageListener. It's worth going back and reading the "MDB
>>> Improvements" thread. However, as John notes, this looks like something that they will be deferring until Java EE 8.
>>>
>>> (Perhaps that's just as well given that we still haven't completed defining the annotations for injecting
>>> MessagingContexts)
>>>
>>> Here in JMS 2.0, the proposals below for message batching don't just apply to MDBs. They apply to Java SE applications
>>> as well. Even though we might want to support the use of CDI features when using JMS in a Java SE environment I think it
>>> unlikely that we would want to make it mandatory - at least as long as CDI is not part of Java SE. We certainly don't
>>> want to make new features such as message batching dependent on it. So we would still need to extend the existing
>>> "old-fashioned" async delivery API to support message batching.
>>>
>>> In addition, if we adopt the proposal for BatchMessage below then message batching would also be made available to
>>> synchronous consumers, and also perhaps when sending messages (if others join Rob in supporting this).
>>>
>>> Nevertheless, EG members need to consider whether adopting either proposal for message batching at this stage would
>>> prejudice any future simplifications along the lines Reza suggested.
>>>
>>> More comments would be welcome. Please indicate your preferences
>>>
>>> Question 1:
>>>
>>> A. We should keep the async batch message delivery feature using the BatchMessageListener API proposed in the Early
>>> Draft
>>> B. We should keep the async batch message delivery feature but use the BatchMessage API proposed below (Nigel, Rob)
>>> C. We should remove the async batch message delivery feature from JMS 2.0 and consider it again for Java EE 8. (Reza)
>>>
>>> Question 2:
>>>
>>> If option (B) is chosen, should we allow BatchMessages to be used by producer applications to send messages more
>>> efficiently? (Such BatchMessages would be broken into their constituent messages before they are added to the
>>> destination)
>>>
>>> Y (Rob)
>>> N
>>> Not sure: (Nigel)
>>>
>>> Question 3:
>>>
>>> if option (B) is chosen, should we extend it to support sync batch delivery as well as async?
>>>
>>> Y (Nigel, Rob)
>>> N:
>>> Not sure:
>>>
>>> Thanks,
>>>
>>> Nigel
>>>
>>