我还不是OSGi的“粉丝”…

我一直在财富100强公司使用企业应用程序。最近，我们使用的产品已经“升级”为OSGi实现。

启动本地cba部署… [2/18/14 8:47:23 727 EST] 00000347 CheckForOasis

最终部署，“以下包将暂停，然后重新启动” 00000143 AriesApplicat I CWSAI0054I:作为应用程序更新操作的一部分

51分钟……每次代码改变…以前的版本(非osgi)在旧的开发机器上部署不到5分钟。

在一台有16g内存和40g空闲磁盘和Intel i5-3437U 1.9 GHz CPU的机器上

The "benefit" of this upgrade was sold as improving (production) deployments - an activity that we do about 4 times a year with maybe 2-4 small fix deployments a year. Adding 45 minutes per day to 15 people (QA and developers) I can't imagine ever being justified. In big enterprise applications, if your application is a core application, then changing it is, rightly so (small changes have potential for far reaching impacts - must be communicated and planned with consumers all over the enterprise), a monumental activity - wrong architecture for OSGi. If your application is not an enterprise application - i.e. each consumer can have their own tailored module likely hitting their own silo of data in their own silo'd database and running on a server that hosts many applications, then maybe look at OSGi. At least, that is my experience thus far.

You can, analogically speaking, change the motor of your car without turning it off. You can customize complex systems for the customers. See the power of Eclipse. You can reuse entire components. Better than just objects. You use a stable platform to develop component based Applications. The benefits of this are huge. You can build Components with the black box concept. Other components don't need to know about hidden interfaces, them see just the published interfaces. You can use in the same system several equal components, but in different releases, without compromise the application. OSGi solves the Jar Hell problem. With OSGi you develop thinking to architect systems with CBD

对于使用Java的每个人来说，有很多好处(我现在只提醒了这些)。

在OSGi上让我抓狂的几件事:

1)实现和它们的上下文加载器有很多怪癖，并且可能有点异步(我们在confluence中使用felix)。与纯spring(没有DM)相比，[main]几乎运行了所有同步。

2)热加载后类不相等。例如，在hibernate上有一个tangosol缓存层。它被Fork.class填充，在OSGi作用域之外。你热加载了一个新的罐子，Fork没有改变。Class[Fork] != Class[Fork]。由于相同的潜在原因，它也会在序列化过程中出现。

3)集群。

您可以解决这些问题，但这是一个非常麻烦的问题，并且会使您的体系结构看起来有缺陷。

对于那些为热插拔做广告的人。OSGi的#1客户端?Eclipse。Eclipse在加载包之后做什么?

它重新启动。

我发现OSGi有以下好处:

每个插件都是一个版本化的工件，它有自己的类加载器。 每个插件都依赖于它所包含的特定jar和其他特定版本的插件。 由于版本控制和隔离的类加载器，同一工件的不同版本可以同时加载。如果应用程序的一个组件依赖于插件的一个版本，而另一个组件依赖于另一个版本，那么它们可以同时加载。

这样，您就可以将应用程序构建为一组按需加载的版本化插件构件。每个插件都是一个独立的组件。就像Maven帮助您构建构建，使其可重复，并由创建它的工件的一组特定版本定义一样，OSGi帮助您在运行时完成这一点。

OSGi提供了以下好处:

■基于Java的可移植安全执行环境

■服务管理系统，可用于跨包注册和共享服务，并将服务提供者与服务消费者分离

■动态模块系统，可用于动态安装和卸载 Java模块，OSGi称之为包

轻量级和可扩展的解决方案

我使用OSGi已经有8年左右的时间了，我不得不说，只有当你有业务需要在运行时更新、删除、安装或替换某个组件时，你才应该考虑使用OSGi。这也意味着您应该有一个模块化的心态，并理解模块化的含义。有一些争论说OSGi是轻量级的——是的，这是真的，但也有一些其他的框架是轻量级的，更容易维护和开发。同样的道理也适用于安全java等等。

OSGi需要一个可靠的体系结构才能正确使用，而且在没有任何OSGi参与的情况下，很容易使OSGi系统成为一个独立可运行的jar。