Couple points of clarification on the role the Connector plays in all this.
MDBs might more accurately be called Connector-Driven Beans. They are an open-ended "receive any message from anywhere" model and not tied to JMS (or even asynchronous messaging) and this is a tested part of the platform. There are no restrictions on Connectors and you could have synchronous or asynchronous resource adapters -- and therefore synchronous or asynchronous MDBS. So things are very much wide open.
MDBs were tied to JMS, but that relationship was made generic with the addition of the Connector specification. There is still JMS legacy in the MDB section of the EJB spec and that (coupled with the fact that Connectors are ill understood) makes things rather confusing.
So back on the here and now, here's how JMS feeds "stuff" to MDBs and JavaEE in general through the Connector API. A compliant JMS Connector will have the following things:
- 1 Outbound ResourceAdapter supplying the following factories that produce transactionally-managed resources:
- javax.jms.ConnectionFactory
- javax.jms.QueueConnectionFactory
- javax.jms.TopicConnectionFactory
- 1 Inbound ResourceAdapter to invoke components (MDBs) implementing javax.jms.MessageListener
- 2 AdminObjects
- javax.jms.Queue
- javax.jms.Topic
You can (theoretically) swap out the JMS implementation from one platform and put it into another and all should work. I shouldn't say theoretically as I know people do this, it's just not common.
Given the Connector layer of abstraction between MDBs and JMS, our basic options are:
1. Use the MessageDrivenContext to expose the string data that is used to make the activation config (loosely-typed, static)
2. Use the MessageDrivenContext to expose the activation config object itself (strongly-typed, static)
3. Use the Connector API to expose a JMS-specific object to the MDB (strongly-typed, potentially dynamic)
If some day we want to see JMS message listeners that have several consuming methods, each annotated in a JAX-RS style to specify which kinds of methods they wish to consume, then #1 and #2 will eventually become of little use and legacy.
A solution that falls under #3 is just more of the same. This potential context object exposed as an AdminObject would put it on equal footing with MessageDrivenContext.
All AdminObjects and the MessageDrivenContext object can be consumed via <resource-env-ref> in xml or @Resource in annotation form. It wouldn't be far fetched to think of the MessageDrivenContext as a built-in AdminObject as from the perspective of the application configuration there is no way to tell the difference.
Note the interface I proposed was really only meant to get the ball rolling. As you note, more could be done there like expose more properties to consume vendor-specific data in a loosely coupled fashion. Alternatively (or in addition), the vendor could expose any number of extra methods and people could consume, and possibly change, the vendor-specific data using strongly typed method calls.
Anyway, that's the basic landscape.
-David
On Apr 10, 2012, at 8:55 AM, John D. Ament wrote:
> Marina,
>
> I can run the config object by the JMS group, the only thing is that it would be an odd one. JMS does not specify MDBs, even though it's the only implementation (no other technology uses MDB to receive some kind of message). ActivationConfig is defined in javax.ejb and the established XML format is native to the ejb-jar descriptor (there is no JMS descriptor). It seems like an issue for the EJB container that the EJB container cannot specify the configuration to the MDB (or even to a Session Bean).
>
> John
>
> On Mon, Apr 9, 2012 at 9:49 PM, Marina Vatkina <marina.vatkina_at_oracle.com> wrote:
> Experts, if you are not on the users alias, please check earlier emails on this thread here: http://java.net/projects/ejb-spec/lists/users/archive and subscribe to the alias.
>
> John,
>
> Continuing my questions in this portion of the thread (thanks for the answers on the other part of it)...
>
> I agree with David that List<ActivationConfigProperty> sounds odd (GlassFish e.g. uses internal structures for the common representation of the metadata).
>
> I also agree with David that adding this method to the MessageDrivenContext, if his proposal gets a green light in EE 8, might be temporary solution that we would need to carry on for backward compatibility... So may be a better option really would be a Config/Context object defined by the JMS spec that can be looked up at a predefined location (java:comp/env/jms/JMSXXX) inside an MDB onMessage (and later on anywhere the message listener is configured by the container). The JMS spec can require that the JMS container makes it available with the config metadata when looked up (injected?) in the correct execution context.
>
> What do others think?
>
>
> thanks,
> -marina
>
> John D. Ament wrote:
> David,
>
> thanks for the feed back. Here are my comments below...
>
> On Sun, Apr 8, 2012 at 5:56 PM, David Blevins <david.blevins_at_gmail.com <mailto:david.blevins_at_gmail.com>> wrote:
>
> Quick first thoughts are maybe just return properties instead of
> annotations (the config may have come from xml):
>
> public Properties getApplicationConfigProperties();
>
>
> Personally, doesn't matter. I was using the typed object since in my head everyone maps the XML back to the annotation. The goal is that there needs to be a way to read all configuration on the MDB, regardless of how configured.
>
> Second slightly less quick thought is maybe it's not a great idea
> if we want to get away from the very unexpressive and loosely
> typed activation config. Would be interested in your thoughts on
> this:
>
> http://java.net/projects/ejb-spec/lists/jsr345-experts/archive/2011-12/message/20
>
> That detailed idea is out of scope for Java EE 7 as there is
> currently no plan for another Connector spec version, but very
> intriguing for Java EE 8.
>
>
> Yes, I agree. I quite like the proposal, and support something like it in Seam JMS. It would be a great addition, though I would like better type safety.
>
> Going a bit further off topic (or perhaps on) is that, for me at
> least, seeing the resource adapter metadata is not nearly as neat
> as being able to change it. I can't tell you the number of times
> I've wished I could update the selector for a JMS MDB.
>
> Perhaps a fun alternative to expanding the very generic
> MessageDrivenContext object would be to instead add a standard
> AdminObject the JMS resource adapter would be required to provide.
> The AdminObject could expose configuration in a strongly typed
> way and possibly let you change a few things (as the JMS spec
> group sees fit).
>
> The interface for the AdminObject might look something like this
> (a better name than JmsContext is welcome):
>
>
> While I like the concrete type, there needs to be flex-attributes.
>
>
>
> import javax.jms.Destination;
>
> public interface JmsContext {
>
> /**
> * 5.4.17.1 JMS Message-Driven Beans
> *
> * Corresponds to the standard 'destinationType'
> activation-config-property
> * @return Topic or Queue
> */
> Class<? extends Destination> getDestinationType();
>
> /**
> * 5.4.17.1 JMS Message-Driven Beans
> *
> * Corresponds to the standard 'subscriptionDurability'
> activation-config-property
> * @return true if this is a Topic with durable subscription
> */
> boolean isDurableSubscription();
>
> /**
> * 5.4.15 Message Acknowledgment for JMS Message-Driven Beans
> *
> * Corresponds to the standard 'acknowledgeMode'
> activation-config-property
> *
> * Only AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE are allowed.
> * Default acknowledgeMode is AUTO_ACKNOWLEDGE.
> *
> * @return true if this is a Topic with durable subscription
> */
> AcknowledgeMode getAcknowledgeMode();
>
> /**
> * 5.4.16 Message Selectors for JMS Message-Driven Beans
> *
> * Corresponds to the standard 'messageSelector'
> activation-config-property
> *
> * @return Message Selector string or null
> */
> String getMessageSelector();
>
>
> /**
> * Possible addition
> */
> void setMessageSelector(String selector);
>
> /**
> * Possible addition
> * @return Topic or Queue instance
> */
> Destination getDestination();
>
> }
>
> /**
> * Added this just because having getAcknowledgeMode return an int
> * corresponding to the constants in javax.jms.Session looked
> terrible.
> *
> * We could put this wherever or delete it entirely.
> */
> public enum AcknowledgeMode {
> SESSION_TRANSACTED,
> AUTO_ACKNOWLEDGE,
> CLIENT_ACKNOWLEDGE,
> DUPS_OK_ACKNOWLEDGE;
> }
>
>
>
> -David
>
>
> On Apr 8, 2012, at 6:06 AM, John D. Ament wrote:
>
> > Hello Experts,
> >
> > I raised this JIRA issue, requesting your feedback. I am
> requesting to have a method added to MessageDrivenContext to allow
> MDBs to know more about how they are configured in the
> environment. Please let me know your thoughts.
> >
> > Thanks,
> >
> > John
> >
>
>
>