JMS 和可移植性答案

【问题标题】：JMS and portabilityJMS 和可移植性
【发布时间】：2013-06-04 07:38:31
【问题描述】：

我想知道哪些是实现 MDB 可移植性的最佳实践。我正在开发一个使用ConnectionFactory 以及Queue 和Topic 的应用程序。在一些应用程序服务器（主要是 glassfish 3.1.2.2 和 JBoss EAP 6.1）上测试应用程序时，我发现有这样注释的资源：

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

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

我在某处读到，在 @Resource 中使用 mappedName 属性被认为是不可移植的，因为它是特定于 AS 的。但我也在为上述方法而苦苦挣扎，实际上是在 Glassfish 上工作，而不是在 JBoss 上工作。是否有一种真正可移植的方法来定义 JMS 实体？

非常感谢。

【问题讨论】：

标签： jakarta-ee jms message-driven-bean

【解决方案1】：

例如，如果您从 WebSphere MQ API 更改为通用 JMS，您可能会发现 MQ 中有一些特殊特性没有映射到 JMS。

如果您的来源已经只使用 JMS，唯一真正不同的是获取 ConnectionFactory 的方式。最重要的是，我没有遇到任何差异。

如果您在没有应用程序服务器的情况下使用 JMS 队列（= 没有 JNDI），通常只有连接方式不同。

如果您在应用服务器中使用 JMS 队列（= 使用 JNDI），通常只有 JNDI 名称不同。

对于 MDB，我更喜欢在应用程序服务器特定的描述符文件（而不是源）中配置连接工厂 - 以保持源和配置分开。无论如何，配置应用程序是数据中心的责任。它可能有助于为不同的环境和/或应用程序服务器构建不同的包。

【讨论】：

我想将源代码和配置分开绝对是一个好方法。正如您所说，使用特定于 AS 的部署描述符有助于保持源代码的清洁和真正的可移植性。不得不说，资源不使用注解真的很可惜。

【解决方案2】：

最佳实践是使用 JMS 2.0 注释（当然在支持它的 JMS 实现上）。 JMS 2.0 定义了许多注释以及注入它们的方法，这将有助于您的情况。

JBoss 的问题在于它will support these only in 8.0。

【讨论】：