是否有人在OSGi中部署了企业应用程序并发现它有用？
我可以看到好处，强制模块化，良好的依赖关系定义等。但这些似乎主要是构建相关的改进。
有没有人发现动态替换现有模块很有用？我们倾向于按流程拆分我们的应用程序，说实话，使用更新的库启动应用程序的新实例并不困难。 OSGi会对此有用吗？
更换模块的可靠性如何？令我感到震惊的是，如果你有一个非常忙碌的过程，那么更换正在运行的模块就会充满危险。
答案 0 :(得分：9)
我刚刚在博客上写了we didn't go with OSGi
的原因简而言之，我相信OSGi的基础是可靠的，但它不是为大规模应用程序开发而构建的。它将摩擦引入已经充满挑战的开发/部署过程中。我希望看到OSGi规范更多地关注OSGi的开发人员/用户角色，使其无法参与开发过程。此外，我对JVM仍然没有透明模块标准感到震惊。
答案 1 :(得分：7)
我们的大多数应用程序都是Web应用程序。
我们有一个OSGi胖客户端，可以收集生物识别信息。目前通过指纹卡扫描的照片和指纹。
OSGi对我们的好处是我们可以从中央网站更新插件，而不是使用卸载/安装过程。我们厚厚的客户将遍布美国100多个地方，因此这对我们非常重要。
答案 2 :(得分：4)
我在电信环境中工作。像OSGi这样的东西对我们非常有用。我们将应用程序部署到无法脱机而无法获得收入的客户端。它们每秒处理数千个呼叫。现在，他们必须在维护窗口中进行更新以接受新的修复或更新。
如果我们可以提供修补程序和增强功能作为热部署，那将是一个很大的好处。但当然，在我们可以做之前，有一个风险因素和模拟流量测试的额外测试工作。
OSGi不仅适用于动态更新，它还适用于版本控制等事情，以确保在复杂环境中选择正确的版本。
我们开始研究OSGi，如果我发现更有趣的话，我会发布更新。
答案 3 :(得分：3)
我们在一家大型电信公司使用它。我们已经在生产中使用了2年，现在我们继续添加捆绑包，现在我们有大约110个捆绑包。
操作人员很高兴能够对他们进行精细控制：他们可以开始停止单一功能并监控它们。从理论上讲，我们也可以在生产中热部署新版本，但实际上我们只在进行测试和预测试时使用该功能。
我们广泛的画笔架构基于以下内容：http://servicemix.apache.org/home.html
我们的主要问题是始终尝试在osgi中使用标准的java框架。第二个问题是捆绑导入/导出管理本身。我们正在使用maven插件。
总而言之，我们对这个选择感到满意，但你需要考虑两件事： 1.你愿意与你想添加的任何java框架作斗争吗？ 2.你是否足够严格，不会搞砸你的依赖？