/**
*作者:张荣华(ahuaxuan)
*日期:2008-4-9
**/
1背景
Spring2.5支持使用annotation来配置我们的service,比如如下代码:
这样就表示这个service需要被spring管理,不过只是这样做是不够的,我们还需要在applicationcontext***.xml中加入这么一段:
这么一来这个xxxxxxx包下所有的使用@Service这个注释的对象都会自动的被spring管理。
虽然这样看上去很美好,但是却是不满足我们的需求的,因为我们的service中,或者其他被管理的bean中有时候需要一些配置,比如说String,Integer等等,而且这些配置的值一般都来自Properties文件,一般情况下我们会使用如下这段代码:
这样我们就可以通过${}来引用到properties文件中的值。
不过使用了@service之后,我们就无法通过${}来得到properties中的值了。downpour是spring2.5使用的先行者,他很早就意识到这个问题,通过我们的讨论,确定了解决问题的方向。下面我把这个方案拿出来和大家共享。
2目标:
我们的目标是实现一个Annotation,代码如下:
pic.address和pic.url是properties文件中的两个属性
以上代码中的@Properties就是我们要实现的Annotation,通过name的值作为key去对应的properties中寻找对应的value,并且主动赋值给ImageFileUpload的对应属性。
3步骤:
我们知道,spring在初始化完bean之后我们可以对这些bean进行一定的操作,这里就是一个扩展点,我决定使用BeanPostProcessor这个接口,这个接口中有一个postProcessAfterInitialization方法就是用来做bean的后处理的,一旦一个bean被初始化完成之后,我们就可以对这个bean进行赋值了。
但是考虑到我们项目中不是所有的bean都使用Annotation来注册到spring中的,这些普通的,配置在xml文件中的bean也有用到${}的需求,所以我考虑扩展PropertyPlaceholderConfigurer这个类。我们来分析一下具体的代码。
首先建立一个Annotation,如下:
接着我们实现我们的扩展主类:
最后我们需要在xml文件中配置一下:
这样任何一个bean,不管它是使用annotation注册的,还是直接配置在xml文件中的都可以使用这种方式来注入properties中的值。
下面看一下我在项目中的一个真实的例子,这个类是一个value object,它代表一组配置:
那么在需要用到该vo的地方比如:
就这么多内容就ok了,如果按照原来的办法,我们就需要在xml配置以上两个bean,然后在里面写一堆又一堆的${},肯定能让你看了之后崩溃,至少我差点崩溃,因为它看上去实在是太丑陋了。而现在,我的心情好多了,因为我用这个@Properties(name = "")用的很爽,呵呵,而且即使有些bean是配置在xml文件中的,比如datasource等等,我们还是可以通过${}来进行设值,也就是说这个方案既支持annotation,也支持${},很好,很强大。
结语:
很显然,在spring2.5的时代,以上这个需求是非常平常的,我相信在spring3.0中一定会提供这样的功能,而且我觉得spring2.5应该是一个过渡版本,虽然上面的方案中代码行数并不多,但是我觉得很有价值,应该很有市场才对,也许我们可以把这个东东叫做spring-properties2object-plugin。
题外话:
说点题外话吧,目前在我的项目里,我使用了struts2.0+spring2.5+hibernate3.2,使用struts2.0的时候我使用struts2.0的zero configuration和codebehind,基本上实现了真正意义零配置,剩下的都是一些common的配置,而且很少,不超过150行。在使用spring的时候,我也基本上是使用annotation来注册我的bean,同时使用上面的方案来作为补充,所以applicationContext-xxx.xml中的也是一些common的配置,也是非常少,应该只有200行左右。而hibernate我是使用annotation来配置我的PO,基本没有配置文件。所以整个项目的xml文件中配置的总行数大大下降。
*作者:张荣华(ahuaxuan)
*日期:2008-4-9
**/
1背景
Spring2.5支持使用annotation来配置我们的service,比如如下代码:
@Service("userService")
public class UserServiceImpl extends BaseServiceSupport implements UserService {
public void xxx() {
}
}
这样就表示这个service需要被spring管理,不过只是这样做是不够的,我们还需要在applicationcontext***.xml中加入这么一段:
<context:component-scan base-package="xxxxxxx"/>
这么一来这个xxxxxxx包下所有的使用@Service这个注释的对象都会自动的被spring管理。
虽然这样看上去很美好,但是却是不满足我们的需求的,因为我们的service中,或者其他被管理的bean中有时候需要一些配置,比如说String,Integer等等,而且这些配置的值一般都来自Properties文件,一般情况下我们会使用如下这段代码:
<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> <property name="locations"> <list> <value>classpath:jdbc.properties</value> </list> </property> </bean>
这样我们就可以通过${}来引用到properties文件中的值。
不过使用了@service之后,我们就无法通过${}来得到properties中的值了。downpour是spring2.5使用的先行者,他很早就意识到这个问题,通过我们的讨论,确定了解决问题的方向。下面我把这个方案拿出来和大家共享。
2目标:
我们的目标是实现一个Annotation,代码如下:
@Service
public class ImageFileUpload implements Serializable {
@Properties(name="pic.address" )
private String picAddress;
@Properties(name="pic.url" )
private String picUrl;
private String picServerUrl;
}
pic.address和pic.url是properties文件中的两个属性
以上代码中的@Properties就是我们要实现的Annotation,通过name的值作为key去对应的properties中寻找对应的value,并且主动赋值给ImageFileUpload的对应属性。
3步骤:
我们知道,spring在初始化完bean之后我们可以对这些bean进行一定的操作,这里就是一个扩展点,我决定使用BeanPostProcessor这个接口,这个接口中有一个postProcessAfterInitialization方法就是用来做bean的后处理的,一旦一个bean被初始化完成之后,我们就可以对这个bean进行赋值了。
但是考虑到我们项目中不是所有的bean都使用Annotation来注册到spring中的,这些普通的,配置在xml文件中的bean也有用到${}的需求,所以我考虑扩展PropertyPlaceholderConfigurer这个类。我们来分析一下具体的代码。
首先建立一个Annotation,如下:
/**
* @author ahuaxuan(aaron zhang)
* @since 2008-4-7
* @version $Id: Properties.java 261 2008-04-07 07:03:41Z aaron $
*/
@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Properties {
// String bundle();
String name();
}
接着我们实现我们的扩展主类:
/**
* @author ahuaxuan(aaron zhang)
* @since 2008-4-7
* @version $Id: AnnotationBeanPostProcessor.java 260 2008-04-07 07:03:35Z aaron $
*/
public class AnnotationBeanPostProcessor extends PropertyPlaceholderConfigurer implements BeanPostProcessor, InitializingBean {
private static transient Log logger = LogFactory.getLog(AnnotationBeanPostProcessor.class);
private java.util.Properties pros;
@SuppressWarnings("unchecked")
private Class[] enableClassList = {String.class};
@SuppressWarnings("unchecked")
public void setEnableClassList(Class[] enableClassList) {
this.enableClassList = enableClassList;
}
public Object postProcessAfterInitialization(Object bean, String beanName)
throws BeansException {
Field [] fields = bean.getClass().getDeclaredFields();
for (Field field : fields) {
if (logger.isDebugEnabled()) {
StringBuilder sb = new StringBuilder();
sb.append(" ========= ")
.append(field.getType())
.append(" ============ ")
.append(field.getName())
.append(" ============ ")
.append(field.isAnnotationPresent(Properties.class));
logger.debug(sb.toString());
}
if (field.isAnnotationPresent(Properties.class)) {
if (filterType(field.getType().toString())) {
Properties p = field.getAnnotation(Properties.class);
try {
// StringBuilder sb = new StringBuilder();
// sb.append("set").append(StringUtils.upperCase(field.getName().substring(0, 1)))
// .append(field.getName().substring(1, field.getName().length()));
//
// Method method = bean.getClass().getMethod(sb.toString(), String.class);
// method.invoke(bean, pros.getProperty(p.name()));
本来我是通过set方法来把properties文件中的值注入到对应的属性上去的,后来downpour提供了更好的方案,就是下面这两行代码,虽然这样做破坏了private的功能,同时破坏了封装,但是确实节省了很多代码,建议大家在业务代码中不要这样做,如果做框架代码可以考虑一下。
ReflectionUtils.makeAccessible(field);
field.set(bean, pros.getProperty(p.name()));
} catch (Exception e) {
logger.error(" --- ", e);
}
}
}
}
return bean;
}
@SuppressWarnings("unchecked")
private boolean filterType(String type) {
if (type != null) {
for (Class c : enableClassList) {
if (c.toString().equals(type)) {
return true;
}
}
return false;
} else {
return true;
}
}
public Object postProcessBeforeInitialization(Object bean, String beanName)
throws BeansException {
return bean;
}
public void afterPropertiesSet() throws Exception {
pros = mergeProperties();
}
}
最后我们需要在xml文件中配置一下:
<bean id="propertyConfigurer" class="xx.service.AnnotationBeanPostProcessor"> <property name="locations"> <list> <value>classpath:jdbc.properties</value> </list> </property> </bean>
这样任何一个bean,不管它是使用annotation注册的,还是直接配置在xml文件中的都可以使用这种方式来注入properties中的值。
下面看一下我在项目中的一个真实的例子,这个类是一个value object,它代表一组配置:
@Component
public class Config implements Serializable{
/** */
private static final long serialVersionUID = 8737228049639915113L;
@Properties(name = " online.pay.accounts")
private String accounts;
@Properties(name = " online.pay.user")
private String user;
@Properties(name = " online.pay.password")
private String password;
@Properties(name = " online.transurl")
private String transUrl;
@Properties(name = " online.refundurl")
private String refundUrl;
@Properties(name = " online.query")
private String queryUrl;
```setter and getter method
}
那么在需要用到该vo的地方比如:
@Service(“userService”)
public class UserServiceImpl implements UserService {
@autowired
private Config config;
public void setConfig(Config config) {
This.config = config;
}
}
就这么多内容就ok了,如果按照原来的办法,我们就需要在xml配置以上两个bean,然后在里面写一堆又一堆的${},肯定能让你看了之后崩溃,至少我差点崩溃,因为它看上去实在是太丑陋了。而现在,我的心情好多了,因为我用这个@Properties(name = "")用的很爽,呵呵,而且即使有些bean是配置在xml文件中的,比如datasource等等,我们还是可以通过${}来进行设值,也就是说这个方案既支持annotation,也支持${},很好,很强大。
结语:
很显然,在spring2.5的时代,以上这个需求是非常平常的,我相信在spring3.0中一定会提供这样的功能,而且我觉得spring2.5应该是一个过渡版本,虽然上面的方案中代码行数并不多,但是我觉得很有价值,应该很有市场才对,也许我们可以把这个东东叫做spring-properties2object-plugin。
题外话:
说点题外话吧,目前在我的项目里,我使用了struts2.0+spring2.5+hibernate3.2,使用struts2.0的时候我使用struts2.0的zero configuration和codebehind,基本上实现了真正意义零配置,剩下的都是一些common的配置,而且很少,不超过150行。在使用spring的时候,我也基本上是使用annotation来注册我的bean,同时使用上面的方案来作为补充,所以applicationContext-xxx.xml中的也是一些common的配置,也是非常少,应该只有200行左右。而hibernate我是使用annotation来配置我的PO,基本没有配置文件。所以整个项目的xml文件中配置的总行数大大下降。
评论
davidcen
2008-06-09
kabbesy 写道
Quake Wang 写道
这样做会不会更好一些?
在Config这个class所在的package下面,有一个同名的Config.properties文件,里面有设置同名field的值:
然后实现一个BeanPostProcessor来根据这个约定来注入值。
这样就省了在Config.java文件写一堆的@Properties annotation,如果你觉得在某些情况下properties文件无法保证和field同名这个约定,你也可以再以@Properties annotation为优先设定。
在Config这个class所在的package下面,有一个同名的Config.properties文件,里面有设置同名field的值:
accounts=xxx user=xxx password=xxx
然后实现一个BeanPostProcessor来根据这个约定来注入值。
这样就省了在Config.java文件写一堆的@Properties annotation,如果你觉得在某些情况下properties文件无法保证和field同名这个约定,你也可以再以@Properties annotation为优先设定。
请问有没有在这个设计基础上的成型代码?
等分散到package之后,或许有一天你又会想把它们都集中管理,放入某个xml里边,这个xml名字或许可以叫做package-class-mapping.xml 简称pcm跟hibernate的hbm对应,可以一个文件放一个vo设置,或者根据package放置多个vo设置,总之随你心意:)
kabbesy
2008-06-05
Quake Wang 写道
这样做会不会更好一些?
在Config这个class所在的package下面,有一个同名的Config.properties文件,里面有设置同名field的值:
然后实现一个BeanPostProcessor来根据这个约定来注入值。
这样就省了在Config.java文件写一堆的@Properties annotation,如果你觉得在某些情况下properties文件无法保证和field同名这个约定,你也可以再以@Properties annotation为优先设定。
在Config这个class所在的package下面,有一个同名的Config.properties文件,里面有设置同名field的值:
accounts=xxx user=xxx password=xxx
然后实现一个BeanPostProcessor来根据这个约定来注入值。
这样就省了在Config.java文件写一堆的@Properties annotation,如果你觉得在某些情况下properties文件无法保证和field同名这个约定,你也可以再以@Properties annotation为优先设定。
请问有没有在这个设计基础上的成型代码?
aws
2008-05-12
还是喜欢集中配置在xml里面
罪恶的小手
2008-05-11
没看懂,,
也许我涉足的还不够的缘故吧,,
也许我涉足的还不够的缘故吧,,
lsy
2008-05-07
个人感觉还是喜欢在配置文件里面写${},因为这些全局的设置写在XML里面,很容易找到哪些bean用了这些properties,以后维护修改也不涉及修改代码。反过来如果用annotation,那么对于一个刚接触项目的人,如果他没找到Config就茫然了。(Config配置VO应该很好找,这里只是举个例子
)
风雪涟漪
2008-05-04
看来约定成俗是未来的大方向了。。。。楼主的方案很好,学习了。
andyao
2008-05-04
使用这种方法要注意bean的一些callback methods
下面两种情况使用不到@Properties注入的值
将代码中的postProcessBeforeInitialization和postProcessAfterInitialization互换,在初始化之前注入@Properties注释的filed,可以解决使用InitializingBean的afterPropertiesSet获取不到值得情况。
下面两种情况使用不到@Properties注入的值
- JSR-250的@PostConstruct
- InitializingBean的afterPropertiesSet
将代码中的postProcessBeforeInitialization和postProcessAfterInitialization互换,在初始化之前注入@Properties注释的filed,可以解决使用InitializingBean的afterPropertiesSet获取不到值得情况。
iExploiter
2008-04-28
在下一个项目中就尝试尝试这种做法看看。
linhao
2008-04-12
难道,这是个系列贴?
xyz20003
2008-04-12
Quake Wang所说的意思是
如果有一个com.family168.domain.Student类。
那么他对应的i18n文件就放在com/family168/domain/Student.properties下。
听ajoo说guice是静态绑定模型,可能没办法实现这种动态查找同一个包下对应配置的功能。
如果有一个com.family168.domain.Student类。
那么他对应的i18n文件就放在com/family168/domain/Student.properties下。
听ajoo说guice是静态绑定模型,可能没办法实现这种动态查找同一个包下对应配置的功能。
yizhuo
2008-04-12
xyz20003 写道
不知道有没有可能修改成Quake Wang说的那种自动查找包内同名配置文件的方式。
是说不同包内有同样的设置文件,但是里面的内容不同?
目前我的开发里没有这种需求。如果是开发和生产环境要用不同的代码,可以把不同的文件放进classpath,然后读取classpath里面的文件。
比如test/config/server.properties和main/config/properties,测试环境用前者,生产环境用后者
yizhuo
2008-04-12
ahuaxuan 写道
上面的设置代码在spring只是一段配置?
你指的是setProperty么?我只是写个testcase举例,真正的环境自然是读取property文件。
区别在于,spring要做你写的那些东西,而guice不需要。
xyz20003
2008-04-12
说简化也就是没有xml了而已,也许感觉xml换成了annotation就算是简化了,是说配置文件减少了吗?
用guice支持properties还是第一次见到,谢谢yizhuo的代码了。不知道有没有可能修改成Quake Wang说的那种自动查找包内同名配置文件的方式。
用guice支持properties还是第一次见到,谢谢yizhuo的代码了。不知道有没有可能修改成Quake Wang说的那种自动查找包内同名配置文件的方式。
ahuaxuan
2008-04-12
yizhuo 写道
Guice作同样的事情简单很多
读取properties
读取properties
Injector injector = Guice.createInjector(new AbstractModule() {
@Override
protected void configure() {
Properties properties = new Properties();
properties.setProperty("name", "Guice");
properties.setProperty("description", "Value");
Names.bindProperties(binder(), properties);
}
});
我怎么就没有看出来这方面guice简单很多呢,上面的设置代码在spring只是一段配置,我在原文中已经给出,这个功能上guice并没有什么突出的特点。
而下面这段代码和我原文中的注入代码没有什么本质的区别,要说区别,那么就是,我只要一个annotation(@Properties),而guice需要两个,哪里有什么guice在这方面简单多了之说????
class DummyPropertyClass {
@Inject
@Named("name")
String name;
@Inject
@Named("description")
String description;
}
yizhuo
2008-04-12
Guice作同样的事情简单很多
读取properties
设置对象
调用对象
个人认为,Guice在DI方面比Spring Javaconfig简单很多
读取properties
Injector injector = Guice.createInjector(new AbstractModule() {
@Override
protected void configure() {
Properties properties = new Properties();
properties.setProperty("name", "Guice");
properties.setProperty("description", "Value");
Names.bindProperties(binder(), properties);
}
});
设置对象
class DummyPropertyClass {
@Inject
@Named("name")
String name;
@Inject
@Named("description")
String description;
}
调用对象
DummyPropertyClass instance = injector.getInstance(DummyPropertyClass.class);
assert instance.name.equals("Guice");
assert instance.description.equals("Value");
个人认为,Guice在DI方面比Spring Javaconfig简单很多
温柔一刀
2008-04-11
downpour 写道
Quake Wang果然是经验丰富啊。这里依稀看到了Webwork中类型转化的影子。用在这里真是恰到好处。
呵呵,Quake Wang是习惯了rails,同时更习惯了rails的默认优于配置的原则
downpour
2008-04-10
Quake Wang果然是经验丰富啊。这里依稀看到了Webwork中类型转化的影子。用在这里真是恰到好处。
fujohnwang
2008-04-10
Quake Wang 写道
这样做会不会更好一些?
在Config这个class所在的package下面,有一个同名的Config.properties文件,里面有设置同名field的值:
然后实现一个BeanPostProcessor来根据这个约定来注入值。
这样就省了在Config.java文件写一堆的@Properties annotation,如果你觉得在某些情况下properties文件无法保证和field同名这个约定,你也可以再以@Properties annotation为优先设定。
在Config这个class所在的package下面,有一个同名的Config.properties文件,里面有设置同名field的值:
accounts=xxx user=xxx password=xxx
然后实现一个BeanPostProcessor来根据这个约定来注入值。
这样就省了在Config.java文件写一堆的@Properties annotation,如果你觉得在某些情况下properties文件无法保证和field同名这个约定,你也可以再以@Properties annotation为优先设定。
Convention Over Configuration的理念用的cool啊,呵呵
其实总的理念就是用BeanPostProcessor对bean定义做后处理,至于通过何种方式获取后处理用的数据,那就各家自显神通了,呵呵
ahuaxuan
2008-04-10
Quake Wang 写道
这样做会不会更好一些?
在Config这个class所在的package下面,有一个同名的Config.properties文件,里面有设置同名field的值:
然后实现一个BeanPostProcessor来根据这个约定来注入值。
这样就省了在Config.java文件写一堆的@Properties annotation,如果你觉得在某些情况下properties文件无法保证和field同名这个约定,你也可以再以@Properties annotation为优先设定。
在Config这个class所在的package下面,有一个同名的Config.properties文件,里面有设置同名field的值:
accounts=xxx user=xxx password=xxx
然后实现一个BeanPostProcessor来根据这个约定来注入值。
这样就省了在Config.java文件写一堆的@Properties annotation,如果你觉得在某些情况下properties文件无法保证和field同名这个约定,你也可以再以@Properties annotation为优先设定。
有道理,尤其是用在vo上很方便,那么也就是说可以提供两个功能,一个是基于规则的(这个规则就是properties文件要和vo名称对应),一个是基于annotation的,如果没有annotation就代表这个是基于规则的。
Quake Wang
2008-04-10
这样做会不会更好一些?
在Config这个class所在的package下面,有一个同名的Config.properties文件,里面有设置同名field的值:
然后实现一个BeanPostProcessor来根据这个约定来注入值。
这样就省了在Config.java文件写一堆的@Properties annotation,如果你觉得在某些情况下properties文件无法保证和field同名这个约定,你也可以再以@Properties annotation为优先设定。
在Config这个class所在的package下面,有一个同名的Config.properties文件,里面有设置同名field的值:
accounts=xxx user=xxx password=xxx
然后实现一个BeanPostProcessor来根据这个约定来注入值。
这样就省了在Config.java文件写一堆的@Properties annotation,如果你觉得在某些情况下properties文件无法保证和field同名这个约定,你也可以再以@Properties annotation为优先设定。
发表评论
提醒: 该博客已发表在公共论坛,博客所有留言会成为论坛回贴,留言请注意遵守论坛发贴规则
- 浏览: 106282 次
- 性别:

- 来自: 上海

- 详细资料
搜索本博客
我的相册
100_2076
共 4 张
共 4 张
最新评论
-
如何解决mysql的master-s ...
在实际环境中,使用jdbc:mysql:replication://有一些问题, ...
-- by ahuaxuan -
请问责任链真的是一种设计 ...
用第一种方式实现的职责链可以在runtime选择下一个handler是谁,但是用 ...
-- by taowen -
请问责任链真的是一种设计 ...
如果是gof定义的设计模式,它算是设计模式如果是lz定义的设计模式,或者他不算是 ...
-- by hunter001201 -
xml和annotation的是是非 ...
Readonly 写道ahuaxuan 写道 Model一个field上挂了O/ ...
-- by imKenny -
如何解决mysql的master-s ...
Readonly 写道偶只用过单纯的ReplicationDriver,不过从源 ...
-- by ahuaxuan






评论排行榜