users@ejb-spec.java.net

[ejb-spec users] Re: EJB_SPEC-55 - New method on MessageDrivenContext

From: John D. Ament <john.d.ament_at_gmail.com>
Date: Mon, 9 Apr 2012 13:29:07 -0400

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>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
> >
>
>