自定义扩展@Value的功能
既然了解了一项技术的工作原理，那么接下里就是定制化、自己扩展自己玩了。
备注：由于本人今日身体欠佳，甚是乏累。并且我个人认为如果你对这个基本原理了解了之后，并且还对SpEL中的PropertyAccessor决策原理了解后，自己扩展@Value注解的功能并不是难事，so，I am 准备go sleep去了~
提示：因为Spring上下文默认是这么注册的beanFactory.setBeanExpressionResolver(new StandardBeanExpressionResolver(beanFactory.getBeanClassLoader()));，所以我们的思路应该是替换掉它~
@Value中使用${}读取不存在的key时，不报错而是原样输出的问题
这个问题我觉得也是比较重要的。
如题，我们通用的一个观念是这样的：若使用@Value("${app.full2}")给字段赋值，若key不存在启动应该报错：
Caused by: java.lang.IllegalArgumentException: Could not resolve placeholder 'app.full2' in value "${app.full2}" at org.springframework.util.PropertyPlaceholderHelper.parseStringValue(PropertyPlaceholderHelper.java:174) at org.springframework.util.PropertyPlaceholderHelper.replacePlaceholders(PropertyPlaceholderHelper.java:126) at org.springframework.core.env.AbstractPropertyResolver.doResolvePlaceholders(AbstractPropertyResolver.java:236) at org.springframework.core.env.AbstractPropertyResolver.resolveRequiredPlaceholders(AbstractPropertyResolver.java:210) at org.springframework.context.support.PropertySourcesPlaceholderConfigurer$2.resolveStringValue(PropertySourcesPlaceholderConfigurer.java:172)
这样才符合我们预期。但是我今天自己在单元测试的时候发现我误打误撞写了一个不存在的key，但是，但是启动并没有报错，而且给我原样输出了。
这个现象引发了我的兴趣，必须调查清楚啊~~~
我们上面（包括推荐博文）已经花了长篇大论知道了，解析占位符这款发生在：DefaultListableBeanFactory#resolveDependency中，里面有一句代码是：
@Override public String resolveEmbeddedValue(String value) { if (value == null) { return null; } String result = value; for (StringValueResolver resolver : this.embeddedValueResolvers) { result = resolver.resolveStringValue(result); if (result == null) { return null; } } return result; }
同样的代码不同的现象，问题就出现在这里resolver.resolveStringValue(result)。这里总结一下
给AbstractBeanFactory设置处理器的地方有两个：
第一处：
public abstract class AbstractApplicationContext extends DefaultResourceLoader implements ConfigurableApplicationContext, DisposableBean { protected void finishBeanFactoryInitialization(ConfigurableListableBeanFactory beanFactory) { ... // 若没有指定EmbeddedValueResolver， 这里就用个匿名函数实现 做个保底嘛~~~ if (!beanFactory.hasEmbeddedValueResolver()) { beanFactory.addEmbeddedValueResolver(new StringValueResolver() { @Override public String resolveStringValue(String strVal) { return getEnvironment().resolvePlaceholders(strVal); } }); } ... } }
第二处：
//@since 3.1 public abstract class PlaceholderConfigurerSupport extends PropertyResourceConfigurer implements BeanNameAware, BeanFactoryAware { protected void doProcessProperties(ConfigurableListableBeanFactory beanFactoryToProcess, StringValueResolver valueResolver) { ... // Spring3.0后 加载完配置文件后，会把这个处理器放进Bean工厂里面去。 // New in Spring 3.0: resolve placeholders in embedded values such as annotation attributes. beanFactoryToProcess.addEmbeddedValueResolver(valueResolver); } }
它有两个子类：PropertyPlaceholderConfigurer，它的StringValueResolver实现为一个内部类实现的。
另一个子类PropertySourcesPlaceholderConfigurer，它的实现StringValueResolver为一个lambda表达式。
他俩有个共同点：最终的解析都依赖于PropertyPlaceholderHelper并且，并且ignoreUnresolvablePlaceholders属性均为默认的fasle。
所以得出结论：若你手动配置过上面两个PlaceholderConfigurerSupport子类Bean，并且没有改变过ignoreUnresolvablePlaceholders这个值，那你最终会使用它们去解析${}占位符，从而如果找不到key就启动报错了。
但是若你没有手动配置过，那将最终交给AbstractBeanFactory的那个内部类处理，也就是这句话：return getEnvironment().resolvePlaceholders(strVal);而它最终解析如下：
public abstract class AbstractEnvironment implements ConfigurableEnvironment { // 两个接口方法。显然AbstractBeanFactory默认实现为这个方法，而并非Required的~~~ @Override public String resolvePlaceholders(String text) { return this.propertyResolver.resolvePlaceholders(text); } @Override public String resolveRequiredPlaceholders(String text) throws IllegalArgumentException { return this.propertyResolver.resolveRequiredPlaceholders(text); } } public abstract class AbstractPropertyResolver implements ConfigurablePropertyResolver { // 调用的resolvePlaceholders这个方法，所以默认情况下 即使key不存在 也是没关系的 @Override public String resolvePlaceholders(String text) { if (this.nonStrictHelper == null) { this.nonStrictHelper = createPlaceholderHelper(true); } return doResolvePlaceholders(text, this.nonStrictHelper); } @Override public String resolveRequiredPlaceholders(String text) throws IllegalArgumentException { if (this.strictHelper == null) { this.strictHelper = createPlaceholderHelper(false); } return doResolvePlaceholders(text, this.strictHelper); } }
如上，就能解释了为何有时候你使用@Value找不到key就启动报错，有时候却原样输出呢？ 这就是其根本原因喽~
备注：此处都只指的纯Spring环境，而非Boot环境~~~
关于SpringBoot环境下，默认情况下都是key必须存在的，否则启动报错。原因如下：
@Configuration @AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE) public class PropertyPlaceholderAutoConfiguration { @Bean @ConditionalOnMissingBean(search = SearchStrategy.CURRENT) public static PropertySourcesPlaceholderConfigurer propertySourcesPlaceholderConfigurer() { return new PropertySourcesPlaceholderConfigurer(); } }
而在spring.factories文件里配置有它：
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ org.springframework.boot.autoconfigure.context.PropertyPlaceholderAutoConfiguration
总之：使用@Value注入时请保证key是存在的，否则建议请使用defaultValue语法处理
总结
相信我们都有一个直观感受：@Value注解非常之简单，但功能非常之强大。
同时Spring的知识点都非常具有层次性，正所谓下层基础决定了你的上层建筑。Spring能够这么高的扩展性，得益于它根基的牢固。
本文@Value的能力，绝大部分其实都是SpEL的能力。换句话说：你对SpEL有多了解，决定了你对@Value注解的使用有多了解
Spring工程非常优秀和快速流行的原因之一也是因为如此：屏蔽了巨多复杂实现，并且对developer提供简单易用的API，从而上手非常之容易（潜台词：精通非常的难）
