javashop v6.2 或将移除组件的component.xml文件,采用注解代替

链接

注解说明:移步 == 》 http://www.javamall.com.cn/blog/archives/311

首先说明一下已有组件的原理:

❤️在系统启动,spring加载时,我们判定一个即将实例化到spring容器中的对象否实现组件接口,如果实现则将其写入组件上下文(ComponentContext)的静态变量集合中,并且加载component.xml文件,生成ComponentView(组件视图)和PluginVIew(插件视图)

❤️自定义的监听器(EopContextLoaderListener)执行时,启动组件。根据ComponentView和PluginView正确生成可以正确调用插件的插件桩

修改后的逻辑

❤️在系统启动,spring加载时,我们判定一个即将实例化到spring容器中的对象否实现特定接口,如果实现 组件借口(IComponent) 则将其写入组件上下文(ComponentContext)的静态变量集合中,如果实现了插件接口(IPlugin)则将其写入插件上下文(PluginContext)

❤️自定义的监听器(EopContextLoaderListener)执行时,获取组件上下文中所有的组件,循环遍历从插件上下文中获取到组件对应的插件集合,根据每个组件和插件的注解,映射出正确的ComponentView(组件视图)和PluginVIew(插件视图)。随后,启动组件,根据ComponentView和PluginView正确生成可以正确调用插件的插件桩。

注解类讲解:

插件注解

CustomPlugin(自定义插件注解)

 插件名称 public String name() default “默认插件”;

 组件 public String component() default “组件id”;

 插件 public String plugin() default “插件id”; 

 执行优先级(保留字段 控制执行顺序) public int sort() default 10;

  插件桩集合 public String[] bundle() default “”;

CustomComponent(自定义组件注解)

 组件名称 public String name() default “默认组件”;

 组件id public String beanid() default “”;

 版本 public String version() default “1.0″;

 javashop版本 public String javashop_version() default “3.0.0″;

 作者 public String author() default “javashop”; 

描述 public String description() default “默认描述”;

属性字段基本和component.xml的配置具体参数没什么区别, 所以修改为注解的形式没有大的改动,只是更改了生成 ComponentView和PluginView的方式。

注解使用

在组件插件具体的类上,声明注解即可。

以上是对注解方式的组件的具体使用解释,接下来讲解连带的其它变更

1、组件加载

ComponentLoader(组件加载)在bean实例化之前的方法中,加入了插件上下文(PluginContext)的注册。

新增的插件上下文主要包含一个静态Map类型,key存组件的beanid,value存该组件的插件集合。

2、组件注册

ComponentContext(组件上下文)的注册组件方法中原本加载组件视图的方法被移除

3、组件启动

EopContextLoadListener(Eop上下文启动监听器)中,组件启动前,获取组件上下文中所有的组件视图,然后执行组件加载视图方法。(也就是在组件注册时的方法被延后执行)

随后执行原本的组件启动方法。

*********************************************主要修改部分************************************************

ComponentContext组件上下文核心方法loadComponent修改,为了兼容老版本的组件机制,这里对Bean是否声明了组件注解进行判定:

如果没有声明,那么按照传统的方法获取component.xml生成组件插件视图。

如果有声明,则获取注解信息进行组件和插件视图的生成。

*********************************************************************************************************

为什么组件机制使用注解实现

spring用注解的方式来管理容器中bean的关系,是所有人看的到到优点,使用注解之前,采用在xml中配置文件的繁琐程度不言而喻。使用注解唯一的缺点不外乎是管理松散,不能概括的了解组件、插件和插件桩的关系。但是只要项目结构足够合理,我相信这个问题是可以避免的。

抛开这些不说,作为一个程序员,喜欢看起来可以装X的代码,抛弃xml配置文件才用注解在个人看来是一个提升逼格的方法。哈哈哈哈

注解是什么,如何使用注解,为什么使用注解

注解是什么

注解,可以看作是对 一个 类/方法 的一个扩展的模版,每个 类/方法 按照注解类中的规则,来为 类/方法 注解不同的参数,在用到的地方可以得到不同的 类/方法 中注解的各种参数与值。

怎么使用注解

1、自定义注解类

注解类上方的注解各种含义,看这个链接http://www.cnblogs.com/peida/archive/2013/04/24/3036689.html

2、枚举类

3、注解使用

通过注解获取到了具体的配置信息,并且打印,那么注解的功能就说完了

以上演示的是类型注解,方法注解则修改注解类中

@Target(ElementType.TYPE)  ===> @Target(ElementType.METHOD)   按照以下方法调用即可

为什么用注解

优点

配置文件

1,集中管理对象和对象之间的组合关系,易于阅读

注解

1,开发速度快

2,编译期间容易发现错误的出处

缺点

配置文件

1,开发速度相对较慢;

2,编译时很难检查出错误,运行中的错误很难定位,调试难度较大。

注解

管理分散,基本每个类上都有;


一个小特性

注解有类似继承这样的机制,A.java 实现了spring的@Component可以被注入到spring容器,但如果自定义的注解有spring的@Component注解的话,那么在具体使用这个自定义注解时候将不需要原本使用的spring注解,具体事例如下:

这是原本应该有的注解形式,一个自定义注解以及一个spring的注解

如果自定义注解 拥有spring的@component注解

那么在具体使用时,可以忽略之前的注解

以上观点为自我理解的结果,如有错误,请指正!~