Injecting JMS configuration at startup instead of hardcoding it in annotations

[orthoxerox]

(Please tag this as a use case)

When I watched the latest JMS 3.0 ideas presentation one of the things I felt was missing was a way to indicate the correct destination and connection factory.

For example, in the "all together" example the destination is hardcoded in an annotation stereotype and the message consumer itself uses some nameless (default?) connection factory.

I regularly have to work with software that has to support swappable MOM and configurable destination names. The traditional approach is to use JNDI to refer to both, but it doesn't work that well without an actual EE server where someone has to configure the connection factory and the destination in some vendor-specific way.

In an ideal case I should be able to package my software along with all the Jakarta Messaging implementations I need in a container that picks the configuration from either environment variables or an injected configuration file at startup and initializes my connection factories, message consumers and destinations.

[m-reza-rahman]

Please correct me if I am wrong, but basically what you are looking for is integration between Jakarta Messaging and what is today MicroProfile Configuration? So something along these lines:

@QueueListener("${task.queue.name}") public void processBuildTask(final ObjectMessage objectMessage)

If this is the case, we had actually proposed this in the Java EE 8+ time frame when Oracle wanted to lead the Configuration JSR. We also wanted this to work in XML descriptors across Java EE. The issue now of course is that in order for this to happen, we need to figure out alignment between Jakarta EE and MicroProfile...

Reza Rahman
Principal Program Manager
Java on Azure

Please note that views here are my own as an individual community member and do not represent the views of my employer.

[orthoxerox]

@m-reza-rahman

Yes, that would work very well for destinations, I think. Annotation-based connection factory definitions (JMSConnectionFactoryDefinition) would also work, but many existing JCA resource adapters for MOM suffer from poor implementation. I think I had a proposal sent to the mailing list regarding that. I'll repost it here in a new issue.

[keilw]

It may be a bit too early, but that's another argument for getting a Jakarta Config Spec flying at least by Jakarta EE 9 or 10 ;-)
Then others like NoSQL could also use it.