精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (3)
|
|
---|---|
作者 | 正文 |
发表时间:2010-04-28
在开发Java程序时,或多或少都会用到一些Java类库程序,自己写的或其他人写的
我们需要将类库Jar放在开发环境的lib目录,然后使用,对于大多数企业项目来说,其实也不算太麻烦
不过我是做WEB开发的,自己的项目中也会部署其他组开发的jar程序,这些jar一变更,我就要全换一遍,麻烦!
而且有些jar的依赖关系还跟我自己的项目有潜在冲突的危险
我只想用,不想负责更新维护,更不想让别的jar污染我的lib目录,于是便有了这个 免部署 运行Java模块 的JIOPi编程风格。
在JIOPi风格中,提供功能的一组Jar包作为一个JIOPi模块发布在JIOPi模块库内(本地/远程),每个模块有一个唯一名用于获取 JIOPi容器使用类似OSGi的模块运行机制,保证不同模块的执行不受干扰
HellWorld展示: 程序功能 1.实例化一个 org.jiopi.ibean.example.module.helloworld.HelloWorldImpl 对象 2.调用对象的 public void helloWorld();方法
//使用中央控制台,指定模块名,获得 模块控制台 对象 ModuleConsole mc = CentralConsole.accessModuleConsole("jiopi.ibean.helloworld.m"); //通过 模块控制台 初始化 指定类 的控制面板(类对象) ControlPanel cp = mc.accessControlPanel("org.jiopi.ibean.example.module.helloworld.HelloWorldImpl", ControlPanel.class); //通过 控制面板 执行 函数 cp.operate("helloWorld", void.class);
在这个JIOPi风格中,只需要在项目内放置一个JIOPiImpl.jar,即可透过JIOPi提供的API访问模块库中的所有程序
这个风格的好处是 调用 模块库 中的程序 无需在项目内放置任何额外的Jar包,但是却过多的失去了Java的代码风格,由于都是反射调用,调用效率也会有一定折扣
于是便出现了 接口部署 风格: 即,在项目的lib内部署要使用模块的 接口Jar包 , 对象依旧从JIOPi中获取,只不过不使用 ControlPanel 接收,而使用 对象的 接口 进行接收 HelloWorld代码如下:
//获取模块控制台,无差异 ModuleConsole mc = CentralConsole.accessModuleConsole("jiopi.ibean.helloworld.i"); //使用接口接收实例化后的对象 HelloWorld hw = mc.accessControlPanel("org.jiopi.ibean.example.module.helloworld.HelloWorldImpl", HelloWorld.class); //使用接口调用方法 hw.helloWorld();
在这种风格下,只有对象实例化的过程需要借助JIOPi的API 当然,我们也可以将实例化的过程交给 Spring,使用依赖注入,代码中便不会出现任何JIOPi的API程序
希望和大家交流一下,你是否能够接受第一种 免部署 方式的代码风格呢? 以及你 对 这种 Jar包 分离的部署方式 有些什么看法?
多谢各位捧场!
参考文章: JIOPi v0.1规范 http://jiopi.iteye.com/admin/blogs/655032 iBean v0.1.0.1 参考实现说明 http://jiopi.iteye.com/admin/blogs/655072 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2010-04-28
第一种和第二种都不好。
我最希望的是得到OSGi的模块分离优势,同时不要加大我的代码开发难度,不要削减开发时编译器和调试器的功用。 能不能实现IoC那种松耦合的方式,不要反射,不要依赖第三方api,使用的都是pojo,然后实时组装? |
|
返回顶楼 | |
发表时间:2010-04-28
xyz20003 写道 第一种和第二种都不好。
我最希望的是得到OSGi的模块分离优势,同时不要加大我的代码开发难度,不要削减开发时编译器和调试器的功用。 能不能实现IoC那种松耦合的方式,不要反射,不要依赖第三方api,使用的都是pojo,然后实时组装? 第二种代码风格是可以使用 Sprint IoC 的呀, ModuleConsole mc = CentralConsole.accessModuleConsole("jiopi.ibean.helloworld.i"); HelloWorld hw = mc.accessControlPanel("org.jiopi.ibean.example.module.helloworld.HelloWorldImpl", HelloWorld.class); 这两行代码在 CentralConsole中提供了快捷访问 CentralConsole.accessControlPanel("jiopi.ibean.helloworld.i",null,"org.jiopi.ibean.example.module.helloworld.HelloWorldImpl", HelloWorld.class); 用Spring的工厂方式注入你的对象就行了,不知道跟你说的有无偏差? |
|
返回顶楼 | |
发表时间:2010-04-28
呵呵,偏差估计就是你这样实现的用意了。因为你给出的HelloWorld实例只演示了反射的场景,没有给出你们期待解决的实际问题。
引用 我只想用,不想负责更新维护,更不想让别的jar污染我的lib目录,于是便有了这个 免部署 运行Java模块 的JIOPi编程风格。 你这样使用反射,按理论上说,本意似乎应该是通过classloader一类的机制(恕我依靠osgi的思路去揣度了)去加载模块中的,但是你没有发觉自己没有向其他人展现模块化的情况吗?我们只看到了一个反射,其他的什么都没有了。也不知道你这里的反射是从何而来。 如果你可以提出模块划分的机制,后续的东西就好玩了,依赖如何控制,类加载如何隔离,不同模块之间的依赖如何解决。服务的暴露,接口的引用。甚至还有对原有组件库的支持和迁移难度。我觉得这些部分才是最终是否选用某个模块管理框架的依据所在,而不是使用反射还是接口的编程方式。 如果上述考虑不周,很可能大大增大系统的开发为维护量,甚至在设计阶段就会出现无法弥补的漏洞。 |
|
返回顶楼 | |
发表时间:2010-04-28
xyz20003,你说的不错,iBean的实现机制确实是使用类似OSGi的模块分离机制,一个JIOPi模块一个ClassLoader,从而避免依赖影响。
这一版本是POJO兼容,也就是将POJO发布成JIOPi模块,从而使用JIOPi容器来进行自动化的模块安装和升级,还没有提出模块间依赖的程序风格,当然,现在也是可以在模块中使用JIOPi的API来访问别的模块的,在一个JIOPi容器内,同名的 模块的一个版本 只会存在一个ClassLoader,所以如果 A模块使用了B1.0模块,C模块也是用了B1.0模块,那么B1.0模块中的单例模式对A C来说是1个,如果A使用了B1.1 C使用了B1.0,那么B的单例对A C而言就是两个 在部署了iBean.jar以后(就是把iBean.jar扔到lib下面就行了,还有一个jiopi.properties文件扔到classpath下面),免部署方式的代码就可以执行了(执行过程中自动下载运行时需要用到的Jar并安装在临时文件夹) 其实JIOPi v0.1就做了这一个事情:把本应该放在lib下面的jar放在JIOPi的资源库里面,本来用是 HelloWorld hw =new org.jiopi.ibean.example.module.helloworld.HelloWorldImpl();的语句 换成使用字符串的反射机制由JIOPi容器获取,从而使用JIOPi容器对Jar文件的自动化版本管理, JIOPi返回的类对象 可以有两种接收方式,反射方式 和 接口 方式,对于懒人(比如我),在执行对效率要求不高的代码段,直接用ControlPanel接收,不部署任何Jar就可以使用别人放在JIOPi资源库里面的所有Jar包程序,资源库的Jar更新后,我的项目用到的Jar也就自动升级了,API升级也没关系,只要我用到的API没变就行 当然这种模式就是代码中会出现JIOPi的API,而且反射效率低,那就用Spring装配吧,不过那代码中不也会出现Spring的代码么?所以。。。如果觉得失去IDE自动查错没关系,那就反射吧,省的在lib下放那么多Jar了 多谢xyz20003观点和提出的问题,让我了解应当再写一些哪方面的文档 |
|
返回顶楼 | |
浏览 2305 次