CODEWITHSUNDEEP
jakarta-eejmsmessage-driven-bean
fabpicca
fabpicca

Reputation: 285

JMS and portability

I'd like to know which are the best practices in order to achieve portability of MDBs. I'm working on a application that uses a ConnectionFactory and both Queue and Topic. While testing the application on some application servers (mainly glassfish 3.1.2.2 and JBoss EAP 6.1) I found that a resource annotated like this:

@Resource(name="jms/myConnectionFactory", lookup="java:/jms/myConnectionFactory")
private ConnectionFactory myConnectionFactory;

@Resource(name="jms/myTopic", lookup="java:/jms/myTopic")
private Topic myTopic;

I've read somewhere that using mappedName property in @Resource is considered not portable since is AS-specific. But I'm struggling also with the aforementioned approach, actually working on Glassfish but not in JBoss. Is there a kind of truly portable approach to define JMS entities?

Thanks a lot.

Upvotes: 1

Views: 254

Answers (2)

2020
2020

Reputation: 2841

The best practice is to use JMS 2.0 annotations (but ofcourse on the JMS implementations that support it). JMS 2.0 defines many annotations and the ways to inject them that would help your situation.

The problem with JBoss is that it will support these only in 8.0.

Upvotes: 0

Beryllium
Beryllium

Reputation: 12988

If you change from WebSphere MQ API to general JMS for example, you might find that there are some special features in MQ which do not map to JMS.

If your source is already only using JMS, the only thing which really differs is the way to get your ConnectionFactory. On top of that I have not encountered any differences.

If you are using JMS queues without an application server (= without JNDI), normally only the ways to connect differ.

If you are using JMS queues in an application server (= using JNDI), normally only the JNDI name differs.

In case of MDBs, I prefer to configure the connection factory in the application server specific descriptor files (and not in the source) - to keep source and confguration separate. It's the data center's responsibility anyway to configure the application. It might help to build different packages for different environments and/or application servers.

Upvotes: 1

Related Questions