David,
I guess maybe I'm missing something. Why for #3 does the injected object
need to be JMS-centric? Even if the listener concept moves to being
methods rather than specific objects, why couldn't we inject the same type
of object as either a method argument or even injected to the class?
JAX-RS supports this concept. Seems like a closer match for
messagecontext.
I'm still more in favor of a method that returns the properties as
configured by the current listener.
John
On Tue, Apr 10, 2012 at 7:30 PM, David Blevins <david.blevins_at_gmail.com>wrote:
> 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/archiveand 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
> > >
> >
> >
> >
>
>