OSGi和遗留系统

我们的需求很多，经常增加，业务变化很快（电信行业运营系统），系统经常需要上线（每个月2-3次上线是常事）
现场维护很为此头疼，上线涉及到客户的考核利益，所以我们一直想把系统做成热部署的，以避免这种频繁上线对考核造成的影响

前面有一个现场在weblogic环境下采用目录方式部署web应用来减少war包上线的影响面，但是这种方式并不是很好的方法

关注OSGi已经一年多了，一直没时间去仔细研究这个，今年是在现场被客户逼的很急了，所以决心实现下系统的热部署，但是如果要对遗留系统做太大的改动，对我们也是很大的风险

OSGi解决不了你的这个问题

why ?

简单看了一下DA-luncher的实现，仅就在Servlet中直接可以调用BundleContext的方法，而不需要使用反射，就比equinox的bridge-servlet要强，有使用DA-luncher的朋友能再深入聊下吗？

DA-Launcher的原理比较简单就是用命令行或web listener来启动OSGi框架。比 org.eclipse.equinox.servletbridge有3点优点：
1 可以简单更改配置，使用不同的OSGi框架，不局限于equinox；
2 listerner加载比servlet加载更优雅；
3 DA-Launcher有较好的目录组织，更规范。
equinox.servletbridge似乎是一个半途而废的东西，设计很乱，没有文档，源代码也不全。DA-Launcher算是一个产品了。

DynamicServlet-Bridge是基于反射来实现OSGi和非OSGi之间的调用的。API设计的还算方便使用，比较清楚。更细节的也不是很了解。

我们做过内嵌的jetty的全部OSGi环境，现在迁移到spring dm server上了。
我们也意识到和你们类似的应用场景：一个复杂的j2ee应用，局部需要热部署(bundle级别)。整个系统进行OSGi改造成本太高。而且OSGi目前还不够成熟，企业级全面应用难度较大。
首先以equinox.servletbridge为基础，做了一个简单的可行性验证。然后才发现DA系列工具的，没有深入使用。

http://www.iteye.com/topic/347890
那里有一些对OSGi热加载的讨论
简单总结一下：
1、OSGi的热加载只是理论上的，还必须遵守很多规则，只要有一点点违反，就做不到热加载，而这些规则都是代码实现级的，很难遵守和检查。
2、在OSGi容器（假设你用了WebLogic10.3这样基于OSGi结构的服务器）中再加入一个OSGi的内容，结果未必如你预期。
3、OSGi目前只合适单机JVM
4、OSGi的复杂度并不低的，如果你想用好，公司没有几个精通Java底层平台的人，那么说得难听点，和找死没有区别。

"OSGi的热加载只是理论上的"这句话我很认同。OSGi仅仅是给热加载提供了一个可能性。要实现这个可能需要自己做工作。例如：

你的web层的一个action，需要调用service层的一个服务实现bean的方法。如果想实现service bean的动态更新，action中需要加入响应service bean（OSGi服务）生命周期的代码。service停止时，action的代码就不能调用service了，需要进入等待状态，或者给用户一个“系统升级中”的提示。OSGi框架可以提供OSGi服务的生命周期的事件，我们需要编写代码来正确处理这些事件，才能让我们的系统拥有动态更新的特性。

使用spring dm framework可以使用到声明型OSGi服务，OSGi服务之间生命周期响应有了一个简单的实现。如果A服务依赖的OSGi服务B不可用，A将处于等待状态，直到B可用。但是这种响应方式不一定满足我们的要求。
而且目前bundle的卸载升级的工具很原始，基本是console级别的。同时更新大量的bundle会很痛苦。

用PHP好了， 什么热的冷的， 都不怕

OSGI 单单是分析服务之间的依赖性， 接口设计等烦烦都烦死了， 不适合快速开发。而且在WEB Site这方面的， OSGI支持的又不好， 那么的图片和页面要同步。

而且应用升级， 何止是增加内容， 还有修改接口， 数据库的Schema更新， 如何更新分布式的环境等等。

这样说吧
我觉得对于一般的系统来说，因为故障停机的时间肯定大于更新时间。
所以与其把精力放在热部署上，不如把精力放在代码质量上。

楼上说的有一定的道理，不过我们的故障时间不会大于更新时间
我们的需求增长太快，热部署还是需要的

whb 兄弟说的生命周期控制，因为我研究的还比较浅，还没有接触到，另外我想问下，Spring DM server支持在jdk1.4环境下运行吗？不会只能在jdk1.5以上吧