Additional ideas on @MessageConsumer annotation :
I was discussing on portability of MDBs in my proposal as below :
Today, we don't have a standard set of activation-config properties that can be provided for a message-driven bean. Every Resource Adapter provides its own set of activation-config properties thus making it difficult for MDBs to switch from one Message server to another. Standardizing the activation-config properties thus helps in seamless portability of MDBs.
Mixing both the ideas of portability and @MessageConsumer annotation, we may probably define some standard set of attributes for the annotation (for example : destination, destinationType, connectionFactory, connectionFactoryType, subscriptionName, messageSelector etc..) to ease the EJB Container to JMS Server integration. We may have to make these attributes optional in order to support consumers outside the container (as Julien was suggesting). But, we can probably document that consumers present inside the containers have to provide these to achieve cleaner integration.
Regards,
Emran.
----- Original Message -----
From: clebert.suconic_at_gmail.com
To: jsr343-experts_at_jms-spec.java.net
Sent: Monday, June 06, 2011 10:38 PM
Subject: [jsr343-experts] Re: [jms-spec users] JMS 2.0 Priorities: Proposal from Emran Shaik
WOW! I swear I didn't read your email before I sent my proposals!
On , Julien Dubois <julien.dubois_at_gmail.com> wrote:
> Hi Emran,
>
> I'm answering your points in order:
>
> 1) (disclaimer: I'm a Spring guy) : we could also have MDB work outside a JEE container (which is useful for batches, or when you don't need a container - I'm currently working on a very specific Netty-based http server for a client, and we don't even have the Servlet API).
>
>
I just proposed a @MessageConsumer annotation. You would have an option outside of the container.
>
>
> 2) Batching JMS messages is a huge issue, I'm all for it. I'd never had the need for timed messages, but now that you speak of it, it looks like a very good idea too (instead of using TimerTasks like I'm used to do). Concerning API enhancements, the transactions/acknowledgement part should also be clarified in the current spec.
>
What a coincidence. +1 on my side.
>
>
>
> 3) In ActiveMQ you can specify a lot of things in your connection string: the IPs of the servers, the timeout, etc... This could be interesting to standardize this.
>
We also have ways to instantiate connection factories directly. I would make a relation to JDBC here. You can make here an analogy to JDBC as you don't need JNDI to make an initial connection.