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