JIOPi v0.3类加载模型

JIOPi v0.3的类加载模型在延续JIOPi v0.2 蓝图初现 的基础上，增加了对CommonLib的加载支持，以及对配置文件重定义和特殊变量修改的支持。

 

CommonLib支持

模块化系统并不能解决所有的问题，因为有些问题必须使用传统的Java类库模式来解决，因此JIOPi提供了CommonLib的支持，即一个模块的实现可以按传统Java开发模式，在lib中引入现有的第三方类库，比如Log4j，JIOPi容器保证在一个运行时环境，相同的CommonLib的Jar(文件名相同)只会被加载一次，即使这个Jar被放在了Context的lib中。

 

Jar依赖问题的解决

由于传统Java类库的开发不是按照模块化系统来做的，因此JIOPi容器无法自动解决Jar的依赖冲突。为了避免依赖冲突，JIOPi提出了ComonLib Group的概念，由用户来保证一个Group内的Jar包不应出现任何依赖冲突，并且一个模块在使用CommonLib时，必须从同一个Group中引入Jar包

 

本地文件夹配置

无论是模块，还是CommonLib，都可能需要用到本地文件系统，这一般是通过properties文件或xml文件来配置的，如log4j.xml，为了体现JIOPi的实现类细节忽略思想，JIOPi提供了对这两类文件进行内容替换的特性，可使用变量来配置相对路径，具体参见 http://jiopi.iteye.com/blog/682454 文中的配置文件说明片段

 

替换的规则是这样的，首先查找申请的文件，如log4j.xml，如果找到，则尝试查找同名的.jiopi结尾的文件，如log4j.xml.jiopi，如果找到，则将内面的预制变量进行替换，重命名后返回，以确保程序拿到的是已经被替换过内容的配置文件

 

配置文件覆盖

配置文件覆盖是指允许从Context中替换运行时所需的配置文件，从Context中读取的配置文件不会做任何内容替换,因为Context环境必然知道本地文件系统的情况

模块

模块环境中配置文件的替换规则是 在 Context中放置一个这样的文件：

origin_file.jiopi.module_name

如果存在，则系统查找匹配的版本，从最匹配的开始找起，如 origin_file.jiopi.module_name.1.0.0.0

然后 origin_file.jiopi.module_name.1.0.0

如果都不存在，则返回 origin_file.jiopi.module_name

返回时会自动改名，避免资源的请求文件名和返回的文件名不一致的问题

 

CommonLib

CommonLib的替换查找是查找 origin_file.jiopi.pool_name.group_name文件

其中pool_name是在jiopi.properties文件中配置的