我在维基百科和其他网站上读过关于OSGi的文章,但我并没有真正看到大局。它说它是一个基于组件的平台,并且您可以在运行时重新加载模块。同样,到处都给出的“实际示例”是Eclipse插件框架。
我的问题是:
OSGi清晰而简单的定义是什么? 它能解决什么常见问题?
所谓“常见问题”,我指的是我们每天都要面对的问题,比如“OSGi能做些什么来让我们的工作更高效/有趣/简单?”
我在维基百科和其他网站上读过关于OSGi的文章,但我并没有真正看到大局。它说它是一个基于组件的平台,并且您可以在运行时重新加载模块。同样,到处都给出的“实际示例”是Eclipse插件框架。
我的问题是:
OSGi清晰而简单的定义是什么? 它能解决什么常见问题?
所谓“常见问题”,我指的是我们每天都要面对的问题,比如“OSGi能做些什么来让我们的工作更高效/有趣/简单?”
当前回答
我发现OSGi有以下好处:
每个插件都是一个版本化的工件,它有自己的类加载器。 每个插件都依赖于它所包含的特定jar和其他特定版本的插件。 由于版本控制和隔离的类加载器,同一工件的不同版本可以同时加载。如果应用程序的一个组件依赖于插件的一个版本,而另一个组件依赖于另一个版本,那么它们可以同时加载。
这样,您就可以将应用程序构建为一组按需加载的版本化插件构件。每个插件都是一个独立的组件。就像Maven帮助您构建构建,使其可重复,并由创建它的工件的一组特定版本定义一样,OSGi帮助您在运行时完成这一点。
其他回答
它还被用于在移动端带来额外的中间件和应用程序的可移植性。移动端可用于WinMo, Symbian, Android等。一旦与设备功能集成,就会出现碎片化。
我还不是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.
OSGi提供了以下好处:
■基于Java的可移植安全执行环境
■服务管理系统,可用于跨包注册和共享服务,并将服务提供者与服务消费者分离
■动态模块系统,可用于动态安装和卸载 Java模块,OSGi称之为包
轻量级和可扩展的解决方案
我使用OSGi已经有8年左右的时间了,我不得不说,只有当你有业务需要在运行时更新、删除、安装或替换某个组件时,你才应该考虑使用OSGi。这也意味着您应该有一个模块化的心态,并理解模块化的含义。有一些争论说OSGi是轻量级的——是的,这是真的,但也有一些其他的框架是轻量级的,更容易维护和开发。同样的道理也适用于安全java等等。
OSGi需要一个可靠的体系结构才能正确使用,而且在没有任何OSGi参与的情况下,很容易使OSGi系统成为一个独立可运行的jar。
OSGi会让你的代码莫名其妙地抛出NoClassDefFoundError和ClassNotFoundException(很可能是因为你忘了在OSGi配置文件中导出一个包);因为它有类加载器,它可以使你的类com.example.Foo不能转换为com.example.Foo,因为它实际上是由两个不同的类加载器加载的两个不同的类。它可以在安装Eclipse插件后将Eclipse引导到OSGi控制台。
对我来说,OSGi只是增加了复杂性(因为它为我增加了一个心理模型),因为异常而增加了烦恼;我从未真正需要它“提供”的活力。它是侵入式的,因为它需要为所有模块配置OSGi包;这绝对不简单(在一个更大的项目中)。
因为我的糟糕经历,我倾向于远离那个怪物,非常感谢。我宁愿忍受jar依赖的地狱,因为这比OSGi引入的类加载器地狱更容易理解。