This looks pretty good I think.
Personally, I would have preferred the greater granularity of the
transaction scope. However, I'll also acknowledge that it can be
difficult to comprehend and most probably overkill. I do hope the
request scope has a sensible definition in Java SE/non-web contexts.
Similarly, I personally like the hierarchical model of the JMS 1.x API
slightly better and feel it can be fit fairly nicely into a DI based
solution. However, I'll acknowldge that the DI approach would not
necessarily be very simple and most folks don't seem to have issues with
a flatter "Spring JMS template" style messaging API.
I suggest socializing the API with the larger community soon. I can
certainly help if needed.
On 2/8/2012 10:27 AM, Nigel Deakin wrote:
> I created this new issue a couple of days ago to allow us to track the
> injection of MessagingContext objects separately from the rest of the
> simplified API:
> http://java.net/jira/browse/JMS_SPEC-70
>
> Currently, the simplified API is in the Early Draft but the injection
> of MessagingContext objects is not. However if there is general
> agreement on what is proposed below I propose to include this in the
> Early Draft as well (since supporting this was the main reason for
> defining the simplified API):
>
> Any comments? (If you don't understand what I am proposing, please let
> me know either directly or via the list)
>
> If it's hard to read the text below, the same content may be found in
> the JIRA issue.
>
> I described the requirement as follows:
>
> --------------------------------------------------------
> The simplified API (JMS_SPEC-64) defines a single object,
> javax.jms.MessagingContext, which provides methods for sending and
> receiving messages.
>
> It is proposed that the JMS API define some standard annotations that
> can be used to inject MessagingContext objects into application code.
>
> * The injection point should allow the application define the two
> parameters needed to create a MessagingContext: JNDI name (of the
> connection factory) and sessionMode. Both should be optional with
> suitable defaults.
>
> * The implementation should ideally be implemented using CDI and have
> behaviour consistent with it. However this is not essential.
>
> * It must be possible to use injection in Java EE applications. It is
> desirable but not essential to be able to use injection in Java SE
> applications.
>
> * Injected MessagingContexts must have an appropriate scope and must
> be automatically closed when they fall out of scope.
> --------------------------------------------------------
>
> I've now drafted a new section for the JMS spec that defines how users
> will inject MessagingContext objects. I've added this text, and the
> proposed new annotation interfaces, to the JIRA issue:
> http://java.net/jira/browse/JMS_SPEC-70
>
> I've pasted the same text below. (To see the actual annotation
> definitions, see the JIRA issue).
>
> I'd like to thank Pete Muir, CDI spec lead, helping me define a
> mechanism for injecting MessagingContext objects which
> * Allow JNDI name and sessionMode to be specified in the injection point
> * Ensures injected objects are closed at the end of the request
> * Is consistent with CDI style
> * Is capable of being implemented
>
> I have a working prototype which implements this, based on a proposal
> from Pete, and which I'm happy to share.
>
> I'd also like to acknowledge the help I was given earlier by Reza
> (Rahman) and John (Ament).
>
> --------------------------------------------------------
>
> This section relates to application classes which run in the Java EE
> web, EJB or application client containers and which support injection.
> Section EE.5 of the Java EE specification lists the application
> classes that support injection.
>
> Applications may declare a field of type javax.jms.MessagingContext
> and annotate it with the javax.inject.Inject annotation:
>
> @Inject
> private MessagingContext context;
>
> The container will inject a MessagingContext. It will have request
> scope and will be automatically closed when the request ends. However,
> unlike a normal CDI request-scoped object, a separate MessagingContext
> instance will be injected for every injection point.
>
> The annotation javax.jms.JMSConnectionFactory may be used to specify
> the JNDI lookup name of the ConnectionFactory used to create the
> messaging context. For example:
>
> @Inject
> @JMSConnectionFactory("jms/connectionFactory")
> private MessagingContext context;
>
> If no lookup name is specified or the JMSConnectionFactory annotation
> is omitted then the platform default JMS connection factory will be used.
>
> The annotation javax.jms.JMSSessionMode may be used to specify the
> session mode of the messaging context:
>
> @Inject
> @JMSConnectionFactory("jms/connectionFactory")
> @JMSSessionMode(MessagingContext.AUTO_ACKNOWLEDGE)
> private MessagingContext context;
>
> The meaning and possible values of session mode are the same as for
> the ConnectionFactory method createMessagingContext(int sessionMode):
>
> * In the Java EE application client container, session mode may be set
> to any of MessagingContext.SESSION_TRANSACTED,
> MessagingContext.CLIENT_ACKNOWLEDGE, MessagingContext.AUTO_ACKNOWLEDGE
> or MessagingContext.DUPS_OK_ACKNOWLEDGE. If no session mode is
> specified or the JMSSessionMode annotation is omitted a session mode
> of MessagingContext.AUTO_ACKNOWLEDGE will be used.
>
> * In a Java EE web or EJB container, when there is an active JTA
> transaction in progress, session mode is ignored and the
> JMSSessionMode annotation is unnecessary.
>
> * In a Java EE web or EJB container, when there is no active JTA
> transaction in progress, session mode may be set to either of
> MessagingContext.AUTO_ACKNOWLEDGE or
> MessagingContext.DUPS_OK_ACKNOWLEDGE. If no session mode is specified
> or the JMSSessionMode annotation is omitted a session mode of
> MessagingContext.AUTO_ACKNOWLEDGE will be used.
>
> For more information about the use of session mode when creating a
> messaging context, see section 10.3 of the JMS 2.0 Early Draft,
> "Behaviour of JMS sessions in the Java EE web or EJB container" and
> the API documentation for the ConnectionFactory method
> createMessagingContext(int sessionMode).
>
> --------------------------------------------------------
>
> Here are three simple examples:
>
> 1. Sending a TextMessage in a Java EE web or EJB container.
>
> @Inject
> @JMSConnectionFactory("jms/connectionFactory")
> private MessagingContext messagingContext;
>
> @Resource(mappedName = "jms/inboundQueue")
> private Queue inboundQueue;
>
> public void sendMessageNew(String payload) {
> messagingContext.send(inboundQueue, payload);
> }
>
> 2. Receiving a message synchronously in a Java EE web or EJB container.
>
> @Inject
> @JMSConnectionFactory("jms/connectionFactory")
> private MessagingContext messagingContext;
>
> @Resource(lookup="jms/inboundQueue")
> Queue inboundQueue;
>
> public String receiveMessageNew() {
> SyncMessageConsumer syncMessageConsumer =
> messagingContext.createSyncConsumer(inboundQueue);
> return syncMessageConsumer.receivePayload(String.class);
> }
>
> 3. Receiving a message synchronously from a durable subscription in a
> Java EE web or EJB container.
>
> @Inject
> @JMSConnectionFactory("jms/connectionFactory2")
> private MessagingContext context;
>
> @Resource(lookup="jms/inboundTopic")
> Topic inboundTopic;
>
> public String receiveMessageNew() {
> SyncMessageConsumer syncMessageConsumer =
> context.createSyncDurableConsumer(inboundTopic, "mysub");
> return syncMessageConsumer.receivePayload(String.class);
> }
>
>
>
>
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1913 / Virus Database: 2112/4796 - Release Date: 02/08/12
>
>