• 1. HSF分享毕玄 2010-05-20
  • 2. HSF分享OSGi化历程 和JBoss的集成 和Tomcat的集成 启动过程 与Land的关系
  • 3. OSGi化历程发生于HSF V1.4,历经三个月才完成 四大痛苦,不亚于重写了一遍HSF 带来的好处 模块化,至少现在HSF要改造为core+extensions的结构是非常容易滴; 动态升级带来的些许好处。
  • 4. OSGi化历程痛苦之一 Maven工程 到现在为止都还不是那么的完美 原因在于 OSGi工程需要自己的MANIFEST.MF,而且相对而言,这个文件修改的话还是在eclipse里修改方便一些; 以前的依赖都是单独放在外部的jar包,现在的依赖有些则需要打入当前工程中,同时还需要在MANIFEST.MF的classpath中指定,复杂复杂; 最后的方法是,MANIFEST.MF文件也上传到了SVN,同时自己修改了maven eclipse插件,避免一个bug 当为pde工程时,有些时候mvn eclipse:eclipse后.classpath里面竟然会丢失依赖。
  • 5. OSGi化历程痛苦之二 拆分工程 为了更好的动态化,开始了拆分工程; 拆分的时候也同时发现原来系统的模块化做的并没有想象中好,拆出来的工程总是这个依赖那个等混乱依赖现象; 原则 接口独立为工程; 不常变的Domain类变为单独工程; 所以工程之间的交互转为通过DS来实现; 对于希望做到动态化的工程,严格遵守不export package的游戏规则。
  • 6. OSGi化历程痛苦之三 和JBoss无缝集成 这个后面专题讲。
  • 7. OSGi化历程痛苦之四 团队开发习惯需要改变 不遵守动态化工程的游戏规则; 开发时忘记export-package、import-package,直接就依赖工程了; DS不够友好。
  • 8. 和JBoss的集成关键点 怎么让应用能访问到HSF的一些类,例如HSFSpringProviderBean; 怎么让HSF访问到应用的类,反射调用、反序列化的时候需要;
  • 9. 和JBoss的集成应用访问到HSF的类 还好JBoss提供了一个UnifiedLoaderRepository3,允许外部直接把加载后的class塞到相应的JBoss classloader中; so...HSF启动时,将需要让应用访问的类放到JBoss的classloader里,同时也做到了控制哪些类一定要用HSF包里的。
  • 10. 和JBoss的集成HSF访问到应用的类 这个还好是equinox; equinox允许通过Hook机制拦截每个OSGi Bundle加载类的过程; so...HSF启动时就将JBoss的classloader注入到这个Hook里,在加载应用的类时,Bundle上肯定是加载不到的,加载不到后我们就会尝试从JBoss classloader里加载一下。
  • 11. 和Tomcat集成需要解决的问题是一样的 哦,还多一个问题,如何支持.sar Tomcat有个LifecycleListener,只要Tomcat启动就会得到通知,于是自己扫描.sar结尾的目录,并动手; 只是需要依据Tomcat的classloader机制; 让应用用我们写的一个继承了WebappClassLoader的ClassLoader,接下来就一切都在我们的掌握之中了; 创建这个自定义ClassLoader的时候同时注入到HSF中去,这样HSF就可以加载应用的类了。
  • 12. 启动过程JBoss里我们通过一个Service MBean来触发HSF的启动,Tomcat里通过LifecycleListener来启动; 启动后基于DS完成HSF内部所有模块的组装; 当应用初始化HSFSpringConsumerBean时,通过一个静态类拿到HSF OSGi服务,生成代理,注册到ConfigServer; 当应用初始化HSFSpringProviderBean时,通过一个静态类拿到HSF OSGi服务,注册到SocketServer上以及ConfigServer上。
  • 13. 和Land的关系其实...没关系 对于Land来说,HSF只不过是一个OSGi的应用而已; Land会借助HSF的一些思想,帮忙把一些功能在容器级别实现; 例如控制类的加载,不论应用打什么包都没用,以后应用依赖包的管理模式就是如此; 例如core+extension plugins的机制。
  • 14. (本页无文本内容)