想做个基于OSGI插件体系的web开发框架，欢迎大家拍砖

楼主的想法很好，xyz20003 对OSGi的点评也十分到位，构建模块化系统以重用模块也是我的追求。

因此我构建了JIOPi模块化编程风格

JIOPi的设计思路源于工业化系统，每个大型工业化产品都是大量使用了标准化零件（模块），例子就不用列举了吧

工业化系统的零件连接方式是使用 blueprint 图纸来描述的

因此，我也希望构建一个 blueprint 导向的 Java模块化系统：
已发布参考实现的JIOPi v0.2提供了以下特性

• 与OSGi使用相似的模块隔离机制来避免依赖模块版本冲突
• 使用Spring嵌入式容器模式，提高容器的兼容性，目前可与Spring一同工作
• 使用非运行时标注使得JIOPi模块的Jar包可直接作为POJO使用
• 统一模块库减少应用的lib目录中Jar包的个数和提供模块的自动升级机制
• 接口访问风格兼容传统Java编程风格
• 免部署访问风格再次降低模块使用难度
• 模块使用为蓝图导向的，可任意更换实现模块以扩充系统功能

以下为标准基本制定但参考实现为完成的特性

• 模块自动装配机和使用方配置装配机制为模块提供更好的可复用性
• JIOPi风格的远程调用
• 将集群模型从服务器级别降低到模块级别，以实现模块无中断升级

以下为希望支持但还不确定的特性

• JIOPi风格的AOP支持
• JIOPi风格的事务支持
• 权限相关

不知楼主是否愿意尝试开发POJO兼容的JIOPi模块呢？

OSGi难用就难用在，遗留系统（包括spring，hibernate之类的东西）都没有考虑一个应用包含多个classLoader的情况，因为开发者对框架内部结构不了解，造成出了问题无法解决。这就造成了一种退化现象，在使用osgi的时候，不用框架反而比用了框架更舒服。

不过考虑到每个人对模块化的理解不同，通过一定的设计手段，可以避免模块化造成的一些问题。因为OSGi其实就是多了几个ClassLoader，只要对java类加载熟悉一点儿，耍点儿小手段也是可以把某些问题解决的。

问题是，如果想要纯粹的动态模块化，实现组件的动态插拔和模块间高度的隔离，就无法避免对现有的这些东西进行改造了。诚然，工作量之巨大，不是一般公司能承担起的。

关于OSGi服务粒度太小的误解，主要是对jar用途有先入为主偏见，估计你们认为jar就是class。可都是zip格式的压缩包，似乎没人总说war和ear的粒度小。我想如果bundle不用jar做扩展名，你们就没这么大的误解了。同志们，请把bundle当做一个压缩包来看好不好，bundle可不是你们想像的拿一个jar过来，在MANIFEST.MF里加几行配置就行了。只要我愿意，把war拿过来，配合自定义MANIFEST.MF一样可以当做bundle来用，你们还觉得它的粒度小吗？

去年我一直头疼的是，如何把现有框架和OSGi一起用起来，结果一直没有让我满意的答案。今年迫于现实的压力，不分模块就会影响下一步的进展，现在我宁肯抛弃以前那些框架工具，退化到史前状态也要用OSGi。即便动态模块化无法一次性达到理想状态，模块隔离也足够让我偷笑一阵子了。

可惜现在手头的东西连半成品都算不上，都搞到一定程度再说吧，看到半成品你们就明白了。有些好处是现有东西怎么也达不到的。

我想在的想法是将视图层和控制层这部分全部交由Flex,ext等展现层框架来完成，
中间通过amf,rest,xml等格式传输数据。

服务端Java中没必要，也不应该出现JSP这种东西，所以spring,struts也没必要存在于
这种系统中了，存在反而累赘
至于持久层的问题，现在正在思考中，相信是有解决办法的，实在不行就写JDBC了。

osgi的bundle粒度怎么会小呢，规定每个bundle一个入口类，负责该bundle的所有交互功能，该入口类可以被flex,js直接调用。

说到关键了。所以我们抛弃了OSGI……项目开发中，适合自己的就是最好的，没必要去追求所谓被狂炒的技术。对公司负责，对团队负责，对新人负责……

    我说的服务粒度太小，是因为我看到很多的基本不能再细分的类库都是以jar包形式发布，这些bundle基本都是我们一般意义上的jar。对此我很是困惑，因为按照这种方式发布，系统中的这种简单jar形式的bundle会多到不可接受，毕竟用到的第三方类库很容易超过100个jar的。

    我自己想到的方法和你所说的有些类似，就是将这个“jar”当成压缩包，将它的一些依赖直接打包到这个bundle内部。bundle对外只依赖有business含义的service。确实有种类似ear，war的感觉。但是这个方法的问题在于会有大量的lib形式的jar在不同的bundle直接重复。

     目前我还没有找到一个比较平衡的方法来解决这个问题，暂时的思路是先不管重复，打进来再说。然后看重复的这些是否可以提起出来作为标准服务提供。举个例子，写日志用到log4j或者slf4j + logback，解析xml用到jdom，所有的bundle都有这个需要，考虑提取到一个或若干个bundle来提供这些基础的通用功能。不过这个似乎和直接把这些类库当成service用似乎又差别不大？

    xyz20003，能否请教一下你是怎么在你的bundle里面处理这些小粒度的常用的类库形式的依赖的？谢谢！

我觉得，你首先应该消除一个误区：所有bundle都是service吗？我觉得不是。

我更愿意把OSGi作为一个平台来看待，把提供OSGi基本功能的引擎作为核心（kernal），在上面搭建一层公共类库（library），公共类库之上的是平台支撑层（platform），在平台层次之上再搭建应用（application）和插件（plugin）。

你说的100个类库，我会放在公共类库一层（library），而公共类库这一层的目的是提供依赖，这里面没有服务。有人要问，既然公共类库不是服务，为何不直接放到核心里，我的回答，为了保证核心足够小，足够轻便。

实际上公共类库这一层全是静态的，只有进入了平台层，我才开始进行一系列初始化，使用下面公共类库的支持，构建并暴露服务。平台一层上需要封装database，tx，mvc，ioc，aop，orm这些东西，并把他们分门别类的注册为不同服务，提供给其他模块调用。（注：这里请认为我在做梦，目前连一个框架都没封装成功，太难了。）

最后，我们的业务模块会建立在应用层之上，通过下面平台暴露的服务实现实际的业务操作。

这样来说，从平台层以下的三层，应该是稳定不动的。虽然依靠OSGi理论上也能实现热插拔，但是风险很高，一不留神，拔掉一个bundle就有可能把上层所有的应用都挂掉。

而应用层和插件层的目标是设计为完全可热插拔的，到时候，用户想要模块，我就给他挂什么模块，对某个功能不满意，我就让他选插件。

唉，想的很美，不知道这辈子能不能实现。

关于类库重复的问题，我认为：该重复的，必须重复。

举个例子，tomcat-6下的el-api.jar和jbpm4使用的juel.jar冲突。目前的解决办法是把el-api.jar删掉，用juel.jar替换。如果整体结构都是OSGi，我就有可能通过控制bundle的import-package来选择使用底层提供的el-api.jar，还是使用内部的juel.jar。

这部分目前还处于幻想阶段，未实现。等有结果了再继续吹：）

答复skydream，JIOPi规范引入了 Common-lib的类加载机制，以便允许所有JIOPi模块使用相同的现有类库，以保证这些类库中的类不会被加载无数次，希望JIOPi能够得到你的关注和支持。

1. osgi对web的支持还差的远，暂时不要指望实现osgi上的web container了，还是支持一些简单的http协议，然后自己处理好了。比如以 rest + json 对外提供服务，只要最基本的http支持就够用了

2. hibernate也不是必须的，直接jdbc + 类似spring jdbc template 的方式也可以简单搞定，或者用ibatis，还方便做sql调优。虽说这年头不用hibernate总被人看成另类

3. ioc的问题，如果是bundle内部实现，应该不收影响吧？如果是bundle之间注入service，似乎无解，还是老实的用osgi的service注册吧

4. mvc框架在bundle里面的用法，我只想到两个。一个就是你说的每个bundle一个mvc，自己搞定自己。但是这样重复是个问题，还有总不能每个bundle开一个端口吧？ 第二个方法就是提供一个对外的bundle负责请求接入，然后再想办法将请求转到相应的处理bundle，似乎要自己造个大轮子（疑问，有现成的吗？）

5.
6. 我还没有考虑

7. AOP的实际应用场景还是不是特别多的，应该还能忍受吧？

8. “Import-Package: *;resolution:=optional和DyanmicImport-Package: *”这个东东真的很致命，多了之后维护问题，我不敢想象。小项目没有必要搞osgi，大项目的话javaproject过百，package多千，OMG！从这个角度上将，将bundle当成ear，war来用，对外只提供/使用业务级别的servie，将所有非业务的第三方依赖都作为bundle的内部lib打包进来，似乎是个减轻症状的好办法。

9. 热插拔dataSource，这个算了吧，就算是成熟的weblogic也会很痛苦的，一般客户也不至于有这么偏门的要求。

xyz20003，不好意思，麻烦您看一下这个帖子的最后(第7页和第8页)，我和zhangdp_neu有一段关于bundle粒度的讨论，我当时画了几个图，似乎和你的想法有些公共点：

http://www.iteye.com/topic/585157?page=8

当然我的想法也暂时只是想法，正在考虑实现的可能性，能不能搞定就不知道了，走一步看一步了。

    我简单链接一个图片过来吧