是否可以在 Karaf 2.3 上使用 Spring 3.1 而不必担心破坏任何东西?
3 回答
我在这个问题上有点挣扎。基本上我们使用的是 Camel 2.10.1、Spring Integration 2.1.3.RELEASE(是的,我知道两个集成框架),我们使用的是 Spring 3.1.2.RELEASE、activemq 5.7.0 和 Karaf 2.3.0。正如克劳斯所说,OSGi 总是令人担忧,尤其是当您无法控制时
- 第三方 OSGi 清单
- Karaf 特征描述符(这不那么令人担心,因为您可以通过创建自定义分布来解决这个问题)。
我们还使用 Spring DM,因此您基本上可以使用三种 Spring 版本 3.0、3.1 和 2.5.6。您最终可以安装三个版本的 spring-core,例如通过传递依赖解析或其他方式,并且取决于启动顺序等,您可能会遇到讨厌的“使用”约束,这总是很痛苦,有时不容易解决.
我们最终做的是与 Karaf 保持一致并放弃 Spring 3.1.2.RELEASE 以支持 3.0.7,这在我们的案例中很容易,因为 3.0.7 很好。
一般来说,我发现与容器提供的开箱即用的内容保持一致是处理依赖项的合理策略。
使用 OSGi 总是让人担心 :(
Camel 支持 Spring 3.0 和 3.1。所以从骆驼的角度来看,你应该没问题。Karaf 随 Spring 3.0.7 开箱即用,您需要重新配置 Karaf 以使用 Spring 3.1.x。
恕我直言,这是错误的(例如,Karaf 开箱即用地公开 Spring 3.0.7),因为我认为 Karaf 不应强迫用户使用特定的 Spring 版本。但是让最终用户自由选择他们想要使用的 Spring。甚至根据容器中部署的应用程序的需要,让 Spring 3.0、3.1 和 3.2 并排运行。或者至少 Karaf 应该恕我直言,更容易选择开箱即用的 Spring 版本。
Karaf @dev 邮件列表上有关于这个问题的讨论,以及如何解决这个问题。 http://karaf.922171.n3.nabble.com/Apache-Karaf-2-3-0-very-close-tp4026295.html 和这里 http://karaf.922171.n3.nabble.com/Re-3rd -Party-Feature-Definitions-tp4026366.html
当 Karaf 团队在那里列出时,请在这些邮件列表中提高您的声音!
好吧,Karaf 2.3.0 提供了 Spring31 功能。将其作为可选功能提供可能不是最佳选择,但现在标准。关于 2.3.0 系列的 spring 特性是 spring 3.0.x 特性。对于开箱即用的支持,您需要稍等一下 Karaf 3.0