(copying to users_at_jms-spec.java.net)
> On Aug 6, 2015, at 7:16 AM, Nigel Deakin wrote to users_at_ejb-spec.java.net to say:
>
>> I've recently published some proposals to make JMS MDBs simpler and easier to use.
>> https://java.net/projects/jms-spec/pages/JMSListener2
>>
>> Since these proposals are specific to JMS they're being discussed as part of JMS 2.1 (part of Java EE 8). However I
>> think they will be of interest to the wider EJB community.
>>
>> If you're interested in improving MDBs for JMS (which is its most common use case) then please take a look and let
>> me know what you think. Please send comments to JMS equivalent of this forum, which is users_at_jms-spec.java.net
>>
>> Other proposals to improve MDBs for JMS will follow. Ideas include allowing finer control over the lifetime of a MDB.
On 06/08/2015 14:55, Lenny Primak wrote:
> Does this include ability for MDB to listen to temporary JMS queues? I don't see how, although I may not be "getting"
> the spec completely yet.
In the current proposals the new-style MDB will specify the queue or topic being listened to in the same way as it does
now, by its JNDI name:
@MessageDriven
public class MyMessageBean {
@JMSListener(lookup="java:global/Trades", type=JMSListener.Type.QUEUE)
public void processTrade(TextMessage tradeMessage){
...
}
}
You still won't be able to specify a temporary queue or topic since (1) it isn't in JNDI and, more importantly, (2) you
don't know its name when the MDB is deployed.
The issue of listening asynchronously to temporary queues is logged as
https://java.net/jira/browse/JMS_SPEC-141 and
hasn't been forgotten. I think a solution to this may lie in allowing MDBs to be started under application control
rather than when the application is first deployed. I was thinking of that when I mentioned that I intended to make
further proposals "allowing finer control over the lifetime of a MDB".
Nigel