OSGi和遗留系统

最近研究了一下OSGi，准备在我们的web系统上使用
下载了equinox的servletbridge来测试，发现了一些问题：
1，只支持命令行的bundle动态管理，很难在unix上使用
2，eclipse目录放在WEB-INF目录下，很难适应集群部署
3，不好和遗留系统无缝集成，需要对遗留系统进行改造，按照bundle重新构造

前两个问题暂时解决方案：
1，使用反射机制，在servlet上实现命令行的命令
2，将eclipse目录移出到war包以外，通过程序配置完成，对于多机集群，每个机器分别设置一个eclipse插件目录

第三个问题似乎没有办法解决。

欢迎大家来讨论下这三个问题的解决方法

补充一下

第三点的无缝集成需要完成：
1，不修改老的代码
2，新增的bundle依赖的功用类不需要依赖另外的bundle，直接依赖老的代码部分的基础类库

对于第2点，我拿到servletbridge的最新源代码后，发现加载整个OSGi Framework的线程的ClassLoader被重新设置了，这样会造成老的代码和新的Framework加载的bundle不是同一个ClassLoader加载的，这样bundle就无法访问到web应用里被servlet容器加载的类，也就无法达到无缝集成的目标

把老的做成一个Bundle，然后把所有的类Export出来
只不过这样肯定是违反了原来OSGi的初衷

就算你把老系统做成bundle，最多也只能集成服务层。
显示层是很难做到无缝集成的，你要解决很多很多兼容性问题。

servletBridge应用还很弱，很多servlet的功能都不支持，filter、listener都没有，只能曲线救国。

从更深层来看，OSGi的企业级功能就更弱了，要在OSGi上建立一套完整的框架会很累。

从开发习惯上，跟传统的开发方式差别比较大，当然如果公司有RCP的开发经验，那会好点。

你会发现CNFE（ClassNotFoundException）比NPE（NullPointerException）出现还要频繁。

我准备完全用反射来实现对OSGi插入的bundle进行调用，不改变原有系统
现在的问题是由于bundle只能依赖bundle，所以原有系统还是要bundle一下给新的bundle引用
而对于数据库连接池这种资源，因为保留老的功能在原框架下运行，新功能在bundle环境下运行，就需要在原框架下和bundle环境下加载两次连接池，造成资源浪费

不建议你用反射，那个在非框架级的系统中，并不是一种好的手段。
如果你没有好的办法，就把原来的东西作为一个Bundle来处理好了

主要是想保持原业务不做任何改动，如果osgi使用的还比较好，那么再用一个循序渐进的方式来把业务逐步转移到osgi框架上，保持一种和谐的升级方式，以节省资源
一次性的把某类业务转移到osgi上也是可以的，不过这样做的问题是需要做多一些编码，而且也就无法保持一个比较平滑的方式来过渡，也就需要投入更多的时间和人力来完成编码和新框架下的回归测试，这样成本就比较高了

很郁闷我都没机会用到 osgi

刚老同事说要俺研究一下这个