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

产生背景：

 

  目前大部分J2EE开发框架都是基于MVC的分层设计，很少基于可重用模块构建。

  导致不同项目的相似部分都需要重新进行开发，给实际项目开发带来诸多不便。

 

项目目标：

 

  1：通过osgi模块搭建整个J2EE程序

  2：充分提高osgi模块的可重用性，以使某一osgi模块可以轻松应用于另一程序

  3：内建用户模块以缩短程序的开发周期

  4：该框架将整个J2EE程序分为Java部分与页面展示部分，Java部分由一组OSGI插件

       构成，专门负责程序核心逻辑，页面展示部分由Flex，AJAX等负责，专门负责

       程序的页面跳转与显示。

  5：整个Java部分不再引用Jsp,Servlet等J2EE特有的API，完全使用J2SE开发方式

     ，使Java部分代码即可用于J2EE程序也可用于J2SE部分。

  6：每个OSGI插件有且仅有一个入口类供页面显示部分直接调用。

 

>  5：整个Java部分不再引用Jsp,Servlet等J2EE特有的API，完全使用J2SE开发方式
>
>     ，使Java部分代码即可用于J2EE程序也可用于J2SE部分。
>

這裡我非常的不能理解，如果你自己servlet這個specification都捨棄了？難道你自己要另起爐灶？

>  6：每个OSGI插件有且仅有一个入口类供页面显示部分直接调用。

我感覺你的意思是REST + OSGI，可實際上是無論怎樣設計模塊化，頁面都是最難模塊化的地方。

目前使用OSGi遇到的一系列问题：

1。jsp不好整，放到bundle里不好解析，放到bundle外限制太多，bundle里的类都用不了。

2。hibernate不愿意支持OSGi，既没有动态添加entityClass的地方，也没有把entityClass保存起来，而是每次都去reflect。这对hibernate相关的模块化都造成很大影响。以后要修改hibernate的源码。

3。spring里也用到了很多xx，yy，目前先用DynamicImport-Package: *搞定，不知道以后有什么更好的办法。
   因为对spring里如何分模块不了解，所以目前spring的ioc基本已经被废掉了。全部按照service来注册到OSGi中。

4。struts2之类的mvc框架还没试过放到bundle里，恐怕放进去问题也是一样，每个bundle启动一个struts又不是很划算，所以打算先用servlet和filter顶着，这下可能又是造轮子了。

5。统一事务处理问题，照目前的整合程度，只好每个request统一开一个tx了，以后有好办法再说。

6。权限控制，只敢保证先控制到URL权限。

7。AOP因为缺乏spring这种的一体化的容器，所以如果想用aop，只能手工编程实现。

8。模块化和热插拔。用了太多Import-Package: *;resolution:=optional和DyanmicImport-Package: *以后，可以肯定无论是拆掉哪个模块，其他部分都会跟着死掉。

9。之前有人提到过热插拔dataSource，这类的高级事务，还是等上述基本问题都解决了再说吧。

xyz20003的总结很到位呀，osgi开发web应用的问题多多，模块化没有想象中那么美，动态化只是一个传说~~~

这里有个opensource的产品，核心框架基于osgi实现，和楼主的需求很接近，参考参考吧！

http://wso2.org/

目前OSGI开发web还是有很多问题不好解决，不过还是应该支持楼主的探索精神～

osgi离web开发还是有点远，目前连基本的j2se都不够实用，web下servlet, jsp更加难做。

哈哈 不错 不过osgi 完全木用过 一点不会
但为什么不用ejb3呀 ejb3很轻量了

看了楼上的高见，非常高兴。不知道我们的情况是否可以用OSGI。
因为我们不使用JSP技术做展现层，而是采用Flex作为客户端，所有的东西对外都是服务的形式。事务的问题我们原本就不用Spring的AOP，而是自己实现的，用于解决可装配的事务。由于自己实现了一套框架，也基本上不需要Spring多多IOC，我们基本上不需要Spring。至于Hibernate的问题，不知道是否有方法解决。我觉得问题应该不大，似乎有文章说可以解决。

一年前做过这种探讨，后来放弃了，因为做这个轮子是在太累了。

有很多OSGi下的技术问题都需要你探索解决，还有很多基础bundle需要你封装。

搭建架构的时间和难度都难以估计，实在是不值得。

另外，我个人评估，OSGi不适合于搭建业务系统，因为OSGi定义的服务粒度太小，而业务服务的粒度一般都比较大。即使你把架构开发出来，在业务定义和引用的时候，会发现处处受限制。

对于业务系统来说，我觉得IoC还是更好更平易近人的服务组织方式。

OSGi定义的服务粒度太小，而业务服务的粒度一般都比较大

我也感觉到了这点，以jar为bundle的最小单位，对类的引用细到package级别。系统稍大之后，复杂度高的惊人。