当前位置：首页 > 文章列表 > 文章 > java教程 > JakartaEE迁移指南：轻量服务器与JMS配置

JakartaEE迁移指南：轻量服务器与JMS配置

2025-08-06 23:39:38 0浏览收藏

推广推荐

支持 PC / 移动端，安全直达

欢迎各位小伙伴来到golang学习网，相聚于此都是缘哈哈哈！今天我给大家带来《Jakarta EE迁移指南：轻量服务器与JMS配置实践》，这篇文章主要讲到等等知识，如果你对文章相关的知识非常感兴趣或者正在自学，都可以关注我，我会持续更新相关文章！当然，有什么建议也欢迎在评论留言提出！一起学习！

迁移至Jakarta EE与JDK 17：选择轻量级应用服务器及JMS配置实践

随着Java生态系统向JDK 17和Jakarta EE的演进，应用程序从javax命名空间迁移至jakarta面临诸多挑战，尤其是在选择轻量级应用服务器以支持Jakarta WS和Jakarta JMS方面。本文将探讨如何选择合适的服务器来替代传统重量级解决方案，并以OpenLiberty为例，详细介绍其在Jakarta EE环境下的配置优势，同时提供ActiveMQ Artemis在Jakarta JMS上下文中的依赖管理与集成指导，旨在为开发者提供平滑迁移的实用教程。

现代化Java应用迁移挑战

从JDK 8和javax命名空间迁移至JDK 17及jakarta命名空间是当前Java企业应用现代化升级的重要趋势。这一转变带来了显著的优势，如性能提升、新语言特性支持和更开放的生态系统。然而，它也要求应用程序服务器和相关库能够全面支持Jakarta EE规范。对于原先依赖如Wildfly这类功能全面但相对“重型”的应用服务器的解决方案，寻求更轻量、更灵活的替代方案成为一个普遍需求，尤其是在微服务或云原生部署场景下。核心挑战在于找到一个既能支持Jakarta WS（Web Services）和Jakarta JMS（Java Message Service），又能兼顾轻量级和高效能的服务器。

轻量级Jakarta EE服务器选型：OpenLiberty

在众多Jakarta EE兼容的应用服务器中，OpenLiberty是一个极具吸引力的选择。它由IBM开发并开源，以其快速启动、低资源消耗和高度模块化而闻名。OpenLiberty完全支持最新的Java版本（包括JDK 17及更高版本）和Jakarta EE规范（包括Jakarta EE 8、9、10等），使其成为从传统Java EE环境平滑迁移到现代Jakarta EE的理想平台。

OpenLiberty的核心优势：

全面支持JDK 17+和Jakarta EE： 确保应用程序能够充分利用JDK 17的语言特性和性能优化，同时兼容最新的Jakarta EE API。
模块化与可组合性： OpenLiberty允许开发者根据需要选择性地启用特定的Jakarta EE功能（Features）。这意味着您可以只包含应用程序实际使用的API和运行时组件，从而大幅减少服务器的内存占用和启动时间。
轻量级： 相比传统重量级应用服务器，OpenLiberty在资源消耗上表现出色，非常适合容器化部署和微服务架构。
开发者友好： 提供了丰富的开发工具支持，如Maven插件，使得开发、测试和部署流程更加顺畅。

OpenLiberty配置示例：

在OpenLiberty中启用Jakarta WS和Jakarta JMS功能，只需在server.xml配置文件中声明相应的feature即可。以下是一个基本的server.xml配置，展示了如何启用Jakarta EE 9.1的Web服务和JMS功能：

<server description="My Jakarta EE Application Server">
    <featureManager>
        <!-- 启用Jakarta EE 9.1平台的所有功能，或者根据需要选择特定功能 -->
        <feature>jakartaee-9.1</feature> 

        <!-- 如果需要更细粒度控制，可以单独启用以下功能：
        <feature>jaxws-3.0</feature>  <!-- Jakarta Web Services 3.0 -->
        <feature>jms-3.0</feature>   <!-- Jakarta Messaging 3.0 -->
        -->

        <!-- 其他常用功能示例 -->
        <feature>mpConfig-3.0</feature> <!-- MicroProfile Config 3.0 -->
        <feature>cdi-3.0</feature>      <!-- Contexts and Dependency Injection 3.0 -->
    </featureManager>

    <!-- JMS Connection Factory 配置示例 (连接到ActiveMQ Artemis) -->
    <!-- 假设ActiveMQ Artemis Broker运行在localhost:61616 -->
    <jmsConnectionFactory id="myConnectionFactory" jndiName="jms/myConnectionFactory">
        <properties.activeMQBroker url="tcp://localhost:61616"/>
    </jmsConnectionFactory>

    <!-- JMS Activation Spec 配置示例 (用于MDB) -->
    <jmsActivationSpec id="myApp/MyMDB">
        <properties.activeMQBroker url="tcp://localhost:61616" destination="queueName"/>
    </jmsActivationSpec>

    <!-- 应用部署配置 -->
    <applicationManager autoExpand="true"/>
    <webApplication id="myApp" location="myApp.war" contextRoot="/myApp"/>
</server>

在上述配置中，jakartaee-9.1 feature包含了jaxws-3.0和jms-3.0等所有Jakarta EE 9.1的核心功能。如果您只需要部分功能，可以单独列出，以进一步优化服务器的启动时间和资源消耗。

Jakarta JMS与ActiveMQ Artemis集成

对于Jakarta JMS的实现，ActiveMQ Artemis是一个高性能、支持多种协议的消息代理。在迁移到Jakarta EE环境时，关键在于确保您的应用程序代码使用jakarta.jms命名空间，并且所使用的ActiveMQ Artemis客户端库与您的JDK版本和Jakarta EE运行时兼容。

依赖管理：

在Maven项目中，您需要更新或添加以下依赖：

ActiveMQ Artemis客户端库： 确保使用与您的JDK 17和Jakarta EE环境兼容的最新稳定版artemis-jms-client。原问题中提到的2.4.0版本相对较旧，建议升级到2.30.0或更高版本，以获得更好的兼容性和性能。
```
<dependency>
    <groupId>org.apache.activemq</groupId>
    <artifactId>artemis-jms-client</artifactId>
    <version>2.30.0</version> 
</dependency>
```

Jakarta JMS API (可选但推荐)： 虽然Jakarta EE应用服务器（如OpenLiberty）会在运行时提供Jakarta JMS API，但在编译时，为了确保代码正确性，可以在项目中明确引入Jakarta JMS API依赖，并将其作用域设置为provided。这表示该依赖在编译时可用，但在运行时由应用服务器提供，避免了依赖冲突。

<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>9.1.0</version> <!-- 或 10.0.0，取决于您的Jakarta EE版本 -->
    <scope>provided</scope>
</dependency>
<!-- 或者只引入JMS API -->
<dependency>
    <groupId>jakarta.jms</groupId>
    <artifactId>jakarta.jms-api</artifactId>
    <version>3.0.0</version> <!-- 对应Jakarta EE 9/10 的JMS API版本 -->
    <scope>provided</scope>
</dependency>

注意事项：

命名空间转换： 您的所有JMS相关代码（如ConnectionFactory、Connection、Session、MessageConsumer、MessageProducer等）的import语句必须从javax.jms.*更改为jakarta.jms.*。
ActiveMQ Artemis Broker： ActiveMQ Artemis Broker本身通常是独立于应用服务器运行的。您需要确保Broker版本也支持与新客户端的通信。
JNDI配置： 在OpenLiberty中配置JMS连接工厂和激活规范时，需要指定正确的JNDI名称，以便应用程序能够通过JNDI查找并使用这些资源。

迁移注意事项与最佳实践

代码重构： 批量替换javax到jakarta命名空间是核心任务。可以使用IDE（如IntelliJ IDEA的Refactor功能）或专门的迁移工具（如OpenRewrite）来自动化这一过程。
依赖清理： 移除所有旧的javax.*相关的API依赖，确保项目中只包含jakarta.*或兼容Jakarta EE的库。

构建工具配置：

Maven： 确保pom.xml中使用的插件（如maven-compiler-plugin）兼容JDK 17，并且编译目标版本设置为17。

Jakarta EE BOM： 考虑引入Jakarta EE的Bill of Materials (BOM)来管理所有Jakarta EE API的版本，确保一致性。

<dependencyManagement>
<dependencies>
    <dependency>
        <groupId>jakarta.platform</groupId>
        <artifactId>jakarta.jakartaee-api</artifactId>
        <version>9.1.0</version> <!-- 或 10.0.0 -->
        <type>pom</type>
        <scope>import</scope>
    </dependency>
</dependencies>
</dependencyManagement>

全面测试： 迁移后务必进行彻底的功能和性能回归测试，以确保所有模块在新环境下正常运行，尤其关注Web服务端点和JMS消息处理。

总结

将Java企业应用从传统Java EE和JDK 8迁移到Jakarta EE和JDK 17是一项值得投入的现代化升级。选择OpenLiberty作为轻量级应用服务器，结合其卓越的模块化特性和对最新Java及Jakarta EE规范的全面支持，可以显著简化迁移过程。通过正确配置OpenLiberty的features以及更新ActiveMQ Artemis客户端依赖，并遵循jakarta命名空间转换的最佳实践，开发者能够构建出更高效、更易于维护和部署的现代化企业级应用。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~