领先一步
VMware 提供培训和认证,以加速您的进步。
了解更多我们很高兴地宣布今天发布了许多与 Spring Batch 相关的版本。Spring Batch 的一个 bug 修复版本、Spring Batch Admin 的一个 bug 修复版本以及新版 Spring Batch Admin 的一个里程碑版本现已全部可用。
Spring Batch 3.0.3 代表了 Spring Batch 的最新维护版本,它解决了若干增强功能和次要的 bug 修复。Spring Batch 3.0.3 中的新功能包括
在此版本之前,覆盖 Spring Batch 为 JSR-352 配置的作业提供的开箱即用基础设施的唯一方法是将配置包含在作业的上下文中。这阻止了为真正共享的组件配置全局覆盖的能力。使用 3.0.3,您现在可以通过系统属性指定 Spring 配置的位置,该属性可以覆盖现有的基础设施。
使用远程分区时,主节点需要一种方法来通知从节点分区已完成其工作。从历史上看,这是通过每个从节点回复主节点、聚合结果,然后通知主节点所有从节点已完成来实现的。但是,这需要额外的配置,而这些配置可能不是必需的。由于分区作业中的从节点在其与主节点相同的作业存储库中维护其状态,因此主节点只需轮询作业存储库即可查看从节点是否已完成。此版本添加了配置MessageChannelPartitionHandler
以轮询作业存储库而不是等待响应消息的功能。您可以在MessageChannelPartitionHandler
的文档中阅读有关此新功能配置的更多信息。
这不是更新的完整列表,而是突出了主要的新功能。您可以在 Spring Batch 的 Jira 问题跟踪器中查看确切的变化:https://jira.spring.io/browse/BATCH/
我们今天提供的两个 Spring Batch Admin 版本中的第一个是 Spring Batch Admin 1.3 系列的第一个维护版本。此版本解决了一些小错误,其列表可以在此处的 Jira 中找到:https://jira.spring.io/browse/BATCHADM/
去年 SpringOne2GX 上我收到的最大问题是“Spring Batch Admin 发生了什么?”Spring Batch Admin 于 7 月份(去年 SpringOne2GX 之前不久)进行了最后一次更新,但它并没有进行太多功能升级。它发布是为了更新依赖项并解决一些错误。从那时起,我们一直在努力更新许多功能,以使 Spring Batch Admin 焕然一新。今天,我们宣布朝着这一目标迈出的第一步。
作为 2.0.0.M1 版本的一部分,Spring Batch Admin 现在将支持 JSR-352 配置的作业。通过将基于 XML 的配置放到/META-INF/batch-jobs
目录(如规范要求)中,Spring Batch Admin 将加载该作业,以便可以通过 REST 端点和当前 UI 启动。Spring Batch Admin 提供的所有监控方面(查看执行情况、启动/停止/重新启动等)都可用。
随着 Spring 社区从基于 XML 的配置转向基于 Java 的配置,Spring Batch Admin 也紧随其后。从本版本开始,Spring Batch Admin 支持配置一个包来扫描 Java 配置的 Spring Batch 作业。与任何其他批处理作业一样,这些作业将被加载并可供执行,就像它们的 XML 对应项一样。
需要注意的是,虽然 Spring Batch Admin 现在支持基于 Java 的配置,但您不希望与它一起使用@EnableBatchProcessing
。这样做是有原因的。@EnableBatchProcessing
提供了一系列 Spring Batch Admin 已开箱即用提供的基础设施。通过 Java 配置为在 Spring Batch Admin 中使用配置作业与使用@EnableBatchProcessing
完全相同……无需使用该注释。您仍然可以像往常一样自动装配JobBuilderFactory
和StepBuilderFactory
。
作为 Spring XD 团队在其管理 UI 中所做的工作的一部分,他们创建了一套全新的与批处理相关的 REST 端点。此版本将这些端点迁移到 Spring Batch Admin 中供所有人使用。在/batch
路径下,存在一组提供与现有 REST API 类似功能的端点,但功能更强大。新的 API 遵循 HATEOAS 原则,允许 API 发现和遍历。虽然对 HATEOAS 的支持仍在进行中,但此版本提供了我们未来发展方向的概览。
与所有 Spring 项目一样,我们努力在尽可能合理的情况下保持向后兼容性。因此,Spring Batch Admin 2.0 正在经历一些重大变化,以便在将来保持向后兼容性。这些更改包括删除“官方”UI 和弃用旧版 REST API。此版本不包含任何这些更改。这些更改将在 Spring Batch Admin 2.0 正式发布之前进行。我们希望对项目的走向保持开放和透明。
过去几年来,任何关注 UI 领域变化速度的人都很快就会发现,选择一种现代的前端技术并能够在可预见的未来保持向后兼容性现在是不可能的。破坏性更改的速度实在太快了。当将此纳入我们希望提供处于其相关领域前沿的工具的愿望时,我们已决定将 UI 从项目的正式部分中移除。也就是说,我们仍然理解客户端是 Spring Batch Admin 提供的重要组成部分。因此,我们计划提供一系列示例项目,演示几种不同的客户端选项。这将使我们能够以不阻止我们保持向后兼容的方式独立于核心框架/API 演进客户端选项。
我们还将弃用旧版 REST API。新的 API 在 REST API 成熟度模型中向前迈进了一步,从基本的 HTTP 上的 CRUD 发展到对真实资源的支持。虽然新的 REST 端点仍在开发中,但一旦它们功能齐全,我们将弃用旧的端点,以将开发工作集中在改进和发展新的一组端点上。
我们将继续致力于上述更改,并计划在今年第二季度初发布另一个版本。我们对 Spring Batch Admin 的未来感到兴奋,并期待您在Jira、Github、StackOverflow和社交媒体上提供反馈!