想做一个插件化Web应用，就像Confluence和Hudson那样，不需要OSGi这种重量级的东西，不需要热部署。因为有许多遗留系统代码需要支持，尽量不要引入框架依赖，只要支持Servlet2.4标准，添加简单的描述即可形成一个插件。Servlet3.0也许是一种选择，但我们不想等待它的普及，可以考虑将来兼容Servlet3.0。目前基本的思路有以下几点：
1、实现一个微内核，负责插件管理，支持插件根据依赖顺序进行组装（依赖注入、配置初始化）。微内核不依赖于Servlet API。
2、实现Web容器中的插件管理，通过统一的Servlet、Filter、Listener，动态调用每个插件中声明的Servlet、Filter、Listener。实现时尽量考虑兼容Servlet3.0的配置文件。
3、对一些现有系统常用框架提供支持组件，例如：支持struts1.x的插件化打包（struts-config.xml打包到插件中）。
不知道这种需求是否合理，大家是否也有类似想法？如果大家有这方面的需求，是否有必要启动一个开源项目呢？
1 楼
newid
2010-02-09
我之前也有个与楼主一样的想法，并且做过一个简单测试是可以实现的。主要还是在于你对于plugin进来的内容的协助定义。比如eclipse的目录结构定义及plugin.xml定义。还有就是你的内核提供的包要强劲（当然这个不是特别重要）。
这些你定义好了后面添加plugin只要根据定义添加就OK。
螃蟹总要有人先吃的。
对于那些OSGI之类的个人觉得重了。一个应用要做成那样成本太高。
这些你定义好了后面添加plugin只要根据定义添加就OK。
螃蟹总要有人先吃的。
对于那些OSGI之类的个人觉得重了。一个应用要做成那样成本太高。
2 楼
hanfeng
2010-02-10
目前设想插件包就是普通jar包，在META-INF目录下放置插件描述文件。
插件描述文件结构我正在考虑，主要包含插件信息、依赖描述、扩展点描述、扩展实现描述等部分。
插件内部目录结构不做强制限制，推荐采用classpath方式访问插件包中的资源。
插件描述文件结构我正在考虑，主要包含插件信息、依赖描述、扩展点描述、扩展实现描述等部分。
插件内部目录结构不做强制限制，推荐采用classpath方式访问插件包中的资源。
3 楼
kjj
2010-02-10
楼主,我也有这个想法,思路和你的差不多,目前还没下手,节后或许我们还能再交流一下!!
4 楼
xzhome
2010-02-10
之前做过类似的东西，不过是基于spring做的，每个插件jar可以定义不同的jsp，bean和dao，插件的文件名使用固定格式，修改spring的初始化，在tomcat启动时自动把所有jsp，css和js文件复制到web-inf目录下
5 楼
pujia12345
2010-02-10
建议看看php做的joomla系统。完全的插件化
6 楼
rainv
2010-02-10
我也是在找时间做一个类似eclipse插件化的Web软件。。。
7 楼
hzh0725
2010-02-11
做吧，做到最后，也许就做出一个osgi原始形态来，OSGI本来就是很微核，小不能在小.而且东西大并不代表它不灵活，maven就是这样的，只会比ant灵活
8 楼
hanfeng
2010-02-11
hzh0725 写道
做吧，做到最后，也许就做出一个osgi原始形态来，OSGI本来就是很微核，小不能在小.而且东西大并不代表它不灵活，maven就是这样的，只会比ant灵活
如果OSGi在Web应用开发上面不是存在这样那样的问题的话，我也就不用提出这个设想了。所以，和OSGi目标一致，使用场景不同，要求更低一些，例如：不会考虑设计那么复杂的类加载机制。
9 楼
hzh0725
2010-02-12
hanfeng 写道
hzh0725 写道
做吧，做到最后，也许就做出一个osgi原始形态来，OSGI本来就是很微核，小不能在小.而且东西大并不代表它不灵活，maven就是这样的，只会比ant灵活
如果OSGi在Web应用开发上面不是存在这样那样的问题的话，我也就不用提出这个设想了。所以，和OSGi目标一致，使用场景不同，要求更低一些，例如：不会考虑设计那么复杂的类加载机制。
为什么呢？
因为OSGI是平台，在很多程序员眼里web server也是平台，容器,当然搞不好了。
如果你完全准许模块开发，你就应该把web server当作是一个服务，只是在osgi平台上运行的一个插件，其他的web application也是插件，然后同osgi平台功能注册到web server上面去。
现在没有这样的实现，但你可以去修改一些opensource ，比如enquinox,felix,jetty,tomcat,你如果了解osgi的运行机制，完全可以自己写code来实现他们的相互绑定，还是比较简单的。
当然，你如果想把一个web application做为一个osgi的使用场景，比如什么dao, server,web搞插件化，这个需要web server支持，但目前好像还没有什么web server支持这样搞，不过你也可以改jetty的webcontext，你自己写一个osgi web context.也不难。
所有上面这些，你必须要对osgi,webserver行为都很了解，如果你经验不够，可以看看的他们的规范和实现。 不要忘记osgi组织的人，每天都在想这些插件化的问题，当然也包括插件化web应用
10 楼
hanfeng
2010-02-15
hzh0725 说的很对，那确实是OSGi的标准使用方式，在用户允许的情况下我也会这么做的。
目前的考虑是在一个受限的情况下，即用户指定了应用类型，必须是运行于现有主流应用服务器上的Web应用(war)，特别是我们面对的客户一般都要求WAS、WebLogic，这些服务器虽然最新版内部采用OSGi，但却没有形成统一的标准为Web应用提供Web Server的OSGi形式的API。
用户是我们的衣食父母，用户的要求就是圣旨，考虑到目前大多数客户（我们主要是面向银行）的要求，所以有了在此场景下暂时替代OSGi实现模块化的想法。
将来OSGi中的Web Server标准API被所有主流应用服务器支持了，我们肯定会选择OSGi的。
目前的考虑是在一个受限的情况下，即用户指定了应用类型，必须是运行于现有主流应用服务器上的Web应用(war)，特别是我们面对的客户一般都要求WAS、WebLogic，这些服务器虽然最新版内部采用OSGi，但却没有形成统一的标准为Web应用提供Web Server的OSGi形式的API。
用户是我们的衣食父母，用户的要求就是圣旨，考虑到目前大多数客户（我们主要是面向银行）的要求，所以有了在此场景下暂时替代OSGi实现模块化的想法。
将来OSGi中的Web Server标准API被所有主流应用服务器支持了，我们肯定会选择OSGi的。
11 楼
hanfeng
2010-02-22
经过讨论，我的想法应该描述的比较清晰了，大家有何建议？是否当做一个开源项目来运作一下呢？
12 楼
guzhan
2010-06-25
atlassian下的产品，使用的插件平台是开源的，叫atlassian-plugin-framework，当前的版本已经能够支持osgi作为其插件。
我研究过一些它的内容，思想很好，由于atlassian与opensymhony的关系，他们一直使用webwork来作为web层框架，这也限制了他们当前插件系统中仅对webwork定义的action的支持。
它的插件体系中，它自身提供的有webfragement、servlet、filter，当然也包括webwork的action，能够定义自己的“Module”，也可以自己解析，根据自己需要确定其用途，能够在插件中定义自己的扩展点，也可以实现已有的扩展点。
我觉得对于插件化的web应用，不同于portlet的颗粒度，它所提供的扩展点和实现已有的扩展点更灵活。
当前淘宝之类的都在寻求页面可定制和引入其他厂商提供的服务集成到页面，插件化的web是一个很好的选择。
我对这方面也比较有兴趣。
我研究过一些它的内容，思想很好，由于atlassian与opensymhony的关系，他们一直使用webwork来作为web层框架，这也限制了他们当前插件系统中仅对webwork定义的action的支持。
它的插件体系中，它自身提供的有webfragement、servlet、filter，当然也包括webwork的action，能够定义自己的“Module”，也可以自己解析，根据自己需要确定其用途，能够在插件中定义自己的扩展点，也可以实现已有的扩展点。
我觉得对于插件化的web应用，不同于portlet的颗粒度，它所提供的扩展点和实现已有的扩展点更灵活。
当前淘宝之类的都在寻求页面可定制和引入其他厂商提供的服务集成到页面，插件化的web是一个很好的选择。
我对这方面也比较有兴趣。
13 楼
sky3380
2010-06-25
http://www.iteye.com/topic/366158
14 楼
wl95421
2010-06-25
可以考虑JDK自己带的ServiceLoader
加载类路径中/META-INF/services/下的资源
加载类路径中/META-INF/services/下的资源
15 楼
hanfeng
2010-06-28
guzhan 写道
atlassian下的产品，使用的插件平台是开源的，叫atlassian-plugin-framework，当前的版本已经能够支持osgi作为其插件。
我研究过一些它的内容，思想很好，由于atlassian与opensymhony的关系，他们一直使用webwork来作为web层框架，这也限制了他们当前插件系统中仅对webwork定义的action的支持。
它的插件体系中，它自身提供的有webfragement、servlet、filter，当然也包括webwork的action，能够定义自己的“Module”，也可以自己解析，根据自己需要确定其用途，能够在插件中定义自己的扩展点，也可以实现已有的扩展点。
我觉得对于插件化的web应用，不同于portlet的颗粒度，它所提供的扩展点和实现已有的扩展点更灵活。
当前淘宝之类的都在寻求页面可定制和引入其他厂商提供的服务集成到页面，插件化的web是一个很好的选择。
我对这方面也比较有兴趣。
我研究过一些它的内容，思想很好，由于atlassian与opensymhony的关系，他们一直使用webwork来作为web层框架，这也限制了他们当前插件系统中仅对webwork定义的action的支持。
它的插件体系中，它自身提供的有webfragement、servlet、filter，当然也包括webwork的action，能够定义自己的“Module”，也可以自己解析，根据自己需要确定其用途，能够在插件中定义自己的扩展点，也可以实现已有的扩展点。
我觉得对于插件化的web应用，不同于portlet的颗粒度，它所提供的扩展点和实现已有的扩展点更灵活。
当前淘宝之类的都在寻求页面可定制和引入其他厂商提供的服务集成到页面，插件化的web是一个很好的选择。
我对这方面也比较有兴趣。
谢谢，研究一下atlassian-plugin-framework再向你请教。