- 浏览: 32292 次
- 性别:
- 来自: 北京
最新评论
-
wangzaixiang:
leonranri 写道jiopi 写道wangzaixian ...
进入Java模块化系统时代,你准备好了么? -
leonranri:
jiopi 写道wangzaixiang 写道不会写文档,是吧 ...
进入Java模块化系统时代,你准备好了么? -
jiopi:
fitliving 写道jiopi,你好。请教一个弱弱的问题, ...
使用基于Nginx集群策略后置模式避免Session复制 -
fitliving:
jiopi,你好。请教一个弱弱的问题,关于写入hashid 的 ...
使用基于Nginx集群策略后置模式避免Session复制 -
bugu1986:
支持下,过几天会详细了解的
使用JIOPi-iBean实现代码所见即所得-交流代码更方便
请您先登录,才能继续操作
文章列表
[置顶] JIOPi框架下载地址
- 博客分类:
- news
下载地址:http://code.google.com/p/ibean/downloads/list
特别说明(2011.9.9):
由于打包问题,JIOPi-iBean-0.4.0.0-src 中编译好的文件存在问题,因此发布JIOPi-iBean-0.4.0.1,同时修正0.4.0.0内核的小问题
说明:JIOPi-iBean-0.4.0.0-min仅包含需要部署在WEB应用中的Jar包和配置文件,JIOPi的具体实现类会在运行时从配置文件指定的服务器上下载最新版本JIOPi-iBean-0.4.0.1除了需要部署在WEB应用中的Jar文件和配置文件外,还有iBean实现类的Ja ...
在开发Java系统时,很难避免使用第三方类库,比如 缓存程序,Java Mail,等
自定义cache接口实现与缓存框架解耦
http://www.iteye.com/topic/697343
一文让我觉得这个理念应当可以应用于更加广泛的场合。
在上文中有人提到
“自定义接口的做法等同于创造标准,在没有规范标准的缓存框架中创造标准很难。”
将自定义接口称之为创造标准倒也不为过,不过这个标准是以当前系统的调用方式为导向的,使用范围也只是当前系统,并不是以兼容所有实现类为导向的,所以从一般标准的范围来看,自定义接口我认为算不上标准,自定义接口只是为了将自己的系统 ...
无API侵入的JIOPi模块化编程风格达成
——纯POJO风格实现简单邮件发送API调用
API侵入是任何框架都很难避免的问题,而被侵入框架API的程序也很容易被该框架绑定,很难脱离框架运行环境。JIOPi作为一种IOP编程和模块化编程风格(而非框架),一直努力减少额外API的引入,非运行时标注让JIOPi模块完全与POJO兼容,通过IoC框架整合,避免调用代码中再引入额外API。然而IoC框架整合也只是将JIOPi的API从用户的代码中转移到了IoC框架配置文件中,并且需要引入IoC框架。JIOPi 0.4引入了全新的类重定义代码风格,完全避免了使用JIOPi模块而需要引入JIOPi ...
JIOPi v0.4 完成了模块访问的POJO化
说明:如未特殊说明,下文中的 JIOPi 均指 JIOPi v0.4 规范
JIOPi主题:回归POJO
JIOPi v0.4 在继承了JIOPi v0.3 蓝图! 的基础上,采用类重定义方式以避免引入额外API进行依赖注入,新增了以下特征和编程风格
本地开发模式模块库支持
模块中的实现类重定义支持
上下文环境中调用时的实现类重定义支持
重定义实现类允许额外功能扩展
模块内部的依赖注入
WEB容器整合
作为一个模块化系统框架,因为其ClassPath的特殊性(统一部署),为了保证测试时和运行时的运行一致性 ...
前些日子大家在讨论使用Nginx负载均衡和集群,Nginx的确是一个不错的轻量级选择(http://www.iteye.com/topic/676347)
对Java Web容器进行集群时,Session共享是一个大问题,上文的方案使用了 Session共享的中央服务器 解决方案,即sessio ...
首先感谢BeijingOpenParty组织的本次"荷风清韵"IT交流会,以及本次活动的赞助商:Thoughtworks,OReilly,华章图文信息有限公司,人民邮电出版社图灵公司,JetBrains,GeekCook,中科龙梦,Google中国 活动报名地址: http://www.beijing-open-party.org/2010/06/beijing-open-party-2010-06-event-announcement/ 届时,JIOPi也将迎来0.4版本的发布 如果你对Java模块化编程感兴趣 如果你认为OSGi太庞大 如果你想了解轻量级可无缝结合JDK的 ...
使用JIOPi构建工业化模型的Java模块系统系列文章之二模块化系统的设计起点——控制面板
随着编程语言的进步,系统的描绘方法也发生着进化,随着面向对象编程的OO时代的进入,出现了若干系统构建和描述方法,如目前最 ...
使用JIOPi构建工业化模型的Java模块系统系列文章之一
——进入Java模块化系统时代,你准备好了么?
系统模块化是趋势,工业产品是这样,程序设计亦然。
编程语言大致经历了 机器码->汇编->面向过程->面向对象
每一次前进,都向模块化系统化迈进了一步
那么我们的系统模块化了么?对比工业化产品的模块化程度,显然没有,但探索的步伐没有停止
OSGi给我们展示了嵌入式系统中的模块化系统模型,在嵌入式环境中,很成功。但是,这个模块化系统模型却不适合用于嵌入式系统之外的WEB应用。
那么什么是工业化的模块化系统呢?我们首先来看一个工 ...
JIOPi v0.3的类加载模型在延续JIOPi v0.2 蓝图初现 的基础上,增加了对CommonLib的加载支持,以及对配置文件重定义和特殊变量修改的支持。
CommonLib支持
模块化系统并不能解决所有的问题,因为有些问题必须使用传统的Java类库模式来解决,因此JIOPi提供了CommonLib的支持,即一个模块的实现可以按传统Java开发模式,在lib中引入现有的第三方类库,比如Log4j,JIOPi容器保证在一个运行时环境,相同的CommonLib的Jar(文件名相同)只会被加载一次,即使这个Jar被放在了Context的lib中。
Jar依赖问题的解决
由于传 ...
论坛经常会看到交流代码的帖子,然而如果要让帖子上的代码在自己的机器上运行起来,可能不是一件容易的事情,如果没有提供下载包,就得自己新建若干类,然后 复制 粘贴,但其实用到的只是一个接口,如果实现类稍微复 ...
JIOPi v0.3 建立了较为完善的本地模块化系统标准 说明:如未特殊说明,下文中的 JIOPi 均指 JIOPi v0.3 规范 JIOPi主题:蓝图!蓝图!
JIOPi v0.3 在继承了JIOPi v0.2 蓝图初现 的基础上,增加了本地模块化系统的全面支持,新增了以下特 ...
JIOPi v0.2的类加载模型在延续JIOPi v0.1 POJO兼容的基础上,增加了对 JIOPi 蓝图 的支持。 JIOPi v0.1类加载模型参见 http://jiopi.iteye.com/blog/656895 蓝图的类加载规则: JIOPi蓝图由以下Jar包组成: 当前蓝图的Jar包 依赖蓝图的Jar包 因此蓝图模块的类加载器必须将蓝图模块中的Jar进行分类,首先从当前蓝图的Jar包中加载类,如果加载不到,则应当调用依赖蓝图的Jar包所使用的蓝图模块的类加载器进行蓝图的加载,而不应该使用当前类加载器进行类的加载。 特殊加载逻辑:如果能够从当前蓝图的Jar包中加载到类,则应当检测C ...
在JIOPi v0.1中引入了 免部署方式访问Java程序的编程风格 详见: http://www.iteye.com/topic/655312
JIOPi v0.2 带来的是 忽略实现类
在POJO类库中,即便使用了接口与实现类分离的设计模式,在使用一个POJO类库时,还是需要知道很多实现类的细节,比如部署依赖Jar,了解与获取对象实例相关的实现类的使用,即便使用了依赖注入,避免了代码中直接出现实现类的细节,但配置文件中还是会出现,并且很有可能一个很简单的接口的实现却十分复杂,需要依赖若干个Jar包,以至于无论是升级实现还是替换实现都不是一件容易的事情,那干脆让实现类变得透明呢?
...
JIOPi v0.2 建立了类加载模型的基本规则
说明:如未特殊说明,下文中的 JIOPi 均指 JIOPi v0.2 规范
JIOPi主题:蓝图初现在模块程序中增加非运行时JIOPi标注或Jar文件中增加xml配置,模块Jar既可作为JIOPi模块使用,也可作为POJO模 ...
同OSGi的类加载模型相似,多个JIOPi模块运行在同一个JVM之内,但互相并不可见。JIOPi使用与OSGi相似但不完全相同的类加载规则以保证模块间既可以相互隐藏模块的具体实现,又可以通过接口相互使用。
JIOPi v0.1是为兼容纯POJO设计的,可以直接将POJO类库放入JIOPi模块库而无需做任何改动,因此,在JIOPi v0.1的类加载模型中,并没有为模块间的相互依赖提供很好的支持,除非是在特别有意的部署方式下,或使用JIOPi提供的反射机制访问,否则JIOPi模块间的相互访问是比较困难的。
JIOPi的名字(Java Interface Oriented Progra ...