前言
前面的三篇文章，主要用BeanFactory介绍了Spring中IoC容器的两个阶段：容器启动阶段和实例化阶段。接下来的这篇文章主要说的是Spring的统一资源定位策略。
Spring为什么要整这个
写下这篇文章之前的绝大部分时间，我都在思考，为什么要整这个功能。任何一个功能、实现肯定有其道理。那道理是什么呢？有人是这么解释的：
要搞清楚Spring为什么提供这么一个功能，还是从Java SE提供的标准类java.net.URL说起比较好。URL全名是Uniform Resource Locator（统一资源定位器），但多少有些名不副实的味道。
首先，说是统一资源定位，但基本实现却只限于网络形式发布的资源的查找和定位工作，基本上只提供了基于HTTP、FTP、File等协议（sun.net.www.protocol 包下所支持的协议）的资源定位功能。虽然也提供了扩展的接口，但从一开始，其自身的“定位”就已经趋于狭隘了。实际上，资源这个词的范围比较广义，资源可以任何形式存在，如以二进制对象形式存在、以字节流形式存在、以文件形式存在等；而且，资源也可以存在于任何场所，如存在于文件系统、存在于Java应用的Classpath中，甚至存在于URL可以定位的地方。
其次，从某些程度上来说，该类的功能职责划分不清，资源的查找和资源的表示没有一个清晰的界限。当前情况是，资源查找后返回的形式多种多样，没有一个统一的抽象。理想情况下，资源查找完成后，返回给客户端的应该是一个统一的资源抽象接口，客户端要对资源进行什么样的处理，应该由资源抽象接口来界定，而不应该成为资源的定位者和查找者同时要关心的事情。
以上的这段文字来自《Spring揭秘》，写的非常正确。但是我第一遍看的时候，我大致还是没看懂。
可能是我底子确实太差了。也可能是因为写书，总归要写的正式一点，而我对于正式语言的理解能力着实不足。这三大段文字的主要意思就是：
URL能力不足，不能定位所有类型的资源，开发Spring的这群人肯定觉得URL不好使，整了一个比它功能强的家伙
看看Spring是怎么整的
一开始肯定是要先定义一个借口Resource
Resource
package org.springframework.core.io;
import java.io.File;
import java.io.IOException;
import java.net.URI;
import java.net.URL;
public interface InputStreamSource{
//每次调用都将返回一个新的资源对应的java.io.InputStream字节流，调用者在使用完毕后必须关闭该资源
InputStream getInputStream() throws IOException;
}
public interface Resource extends InputStreamSource{
//返回当前Resouce代表的底层资源是否存在，true表示存在
boolean exists();
//返回当前Resouce代表的底层资源是否可读，true表示可读
boolean isReadable();
//返回当前Resouce代表的底层资源是否已经打开，如果返回true，则只能被读取一次然后关闭以避免内存泄露；常见的Resource实现一般返回false；
boolean isOpen();
//如果当前Resouce代表的底层资源能由java.util.URL代表，则返回该URL，否则抛出IOException
URL getURL() throws IOException;
//如果当前Resouce代表的底层资源能由java.util.URI代表，则返回该URI，否则抛出IOException
URI getURI() throws IOException;
//如果当前Resouce代表的底层资源能由java.io.File代表，则返回该File，否则抛出IOException
File getFile() throws IOException;
//返回当前Resouce代表的底层文件资源的长度，一般的值代表的文件资源的长度
long contentLength() throws IOException;
//返回当前Resouce代表的底层文件资源的最后修改时间
long lastModified() throws IOException;
//用于创建相对于当前Resource代表的底层资源的资源，比如当前Resource代表文件资源“D:/test/”则createRelative("test.txt")将返回代表文件资源“D:/test/test.txt”Resource资源。
Resource createRelative(String relativePath) throws IOException;
//返回当前Resource代表的底层文件资源的文件路径，比如File资源：file://d:/test.txt 将返回d:/test.txt，而URL资源http://www.javass.cn将返回“”，因为只返回文件路径
String getFilename();
//返回当前Resource代表的底层资源的描述符，通常就是资源的全路径（实际文件名或实际URL地址）
String getDescription();
}接口提供这些方法，基本上是足够我们日常使用的，除了这个接口，当然也提供了这些接口的sh实现类。
可以看到，有16个实现类，当然，我们常用的并没有那么多，主要有以下几个
- ByteArrayResource。将字节（byte）数组提供的数据作为一种资源进行封装，如果通过InputStream形式访问该类型的资源，该实现会根据字节数组的数据，构造相应的ByteArray-InputStream并返回。
- ClassPathResource。该实现从Java应用程序的ClassPath中加载具体资源并进行封装，可以使用指定的类加载器（ClassLoader）或者给定的类进行资源加载。
- FileSystemResource。对java.io.File类型的封装，所以，我们可以以文件或者URL的形式对该类型资源进行访问，只要能跟File打的交道，基本上跟FileSystemResource也可以。
- UrlResource。通过java.net.URL进行的具体资源查找定位的实现类，内部委派URL进行具
体的资源操作。 - InputStreamResource。将给定的InputStream视为一种资源的Resource实现类，较为少用。
可能的情况下，以ByteArrayResource以及其他形式资源实现代之。
ResourceLoader
其实啦，上面说了半天，都是在说Resource，有了资源，怎么去查找，怎么去定位呢，用ResourceLoader。
这必然，我猜它就是个接口，这么简洁的名字。
ResourceLoader
package org.springframework.core.io;
import org.springframework.util.ResourceUtils;
public interface ResourceLoader {
// CLASSPATH_URL_PREFIX = classpath
String CLASSPATH_URL_PREFIX = ResourceUtils.CLASSPATH_URL_PREFIX;
// 拿到Resource
Resource getResource(String location);
// 拿到ClassLoader
ClassLoader getClassLoader();
}事实证明，我想的还是没错的，但是这个接口也真是够简洁的。
看看实现类吧~
18个，但还是先看画圈的几个吧。
DefaultResourceLoader
public Resource getResource(String location) {
Assert.notNull(location, "Location must not be null");
for (ProtocolResolver protocolResolver : this.protocolResolvers) {
Resource resource = protocolResolver.resolve(location, this);
if (resource != null) {
return resource;
}
}
if (location.startsWith("/")) {
return getResourceByPath(location);
}
else if (location.startsWith(CLASSPATH_URL_PREFIX)) {
return new ClassPathResource(location.substring(CLASSPATH_URL_PREFIX.length()), getClassLoader());
}
else {
try {
// Try to parse the location as a URL...
URL url = new URL(location);
return new UrlResource(url);
}
catch (MalformedURLException ex) {
// No URL -> resolve as resource path.
return getResourceByPath(location);
}
}
}这是DefaultResourceLoader返回Resource的方法，可以看到：
- 看看location是不是以"/"开头，如果是返回ClassPathContextResource类型的资源
- 检查资源路径是否以classpath:前缀打头，如果是，则尝试构造ClassPathResource类型资源并返回。
- 尝试通过URL，根据资源路径来定位资源，如果没有抛出MalformedURLException，有则会构造UrlResource类型的资源并返回；
4.如果还是无法根据资源路径定位指定的资源，则委派getResourceByPath(String) 方法来定位， DefaultResourceLoader 的getResourceByPath(String)方法默认实现逻辑是，构造ClassPathResource类型的资源并返回。
FileSystemResourceLoader虽然是DefaultResourceLoader的继承类，但是在getResourceByPaht方法上就不是返回ClassPathResource，而是返回FileSystemResource
@Override
protected Resource getResourceByPath(String path) {
if (path != null && path.startsWith("/")) {
path = path.substring(1);
}
return new FileSystemContextResource(path);
}ApplicationContext 与资源
前面一直就只是在讲资源，资源定位器，但是，在我们Spring的体现又在哪里？
先看这个图，很明显，ApplicationContext也是ResourceLoader。如果再看两个重要的实现类，你就会懂了。原来如此
ClassPathXmlApplicationContext
FileSystemXmlApplicationContext
剩下的，你说一个bean里面，如果要注入ResourceLoader，或者要注入Resource怎么办呢？
可以这么做
public class FooBar {
private ResourceLoader resourceLoader;
public void foo(String location) {
System.out.println(getResourceLoader().getResource(location).getClass());
}
public ResourceLoader getResourceLoader() {
return resourceLoader;
}
public void setResourceLoader(ResourceLoader resourceLoader) {
this.resourceLoader = resourceLoader;
}
}
然后配置一下bens.xml
<bean id="resourceLoader" class="org.springframework.core.io.DefaultResourceLoader">
</bean>
<bean id="fooBar" class="...FooBar">
<property name="resourceLoader">
<ref bean="resourceLoader"/> </property>
</bean>
有点复杂诶，你说，ApplicationContext不就是资源定位器吗？为什么还要再弄一个新的出来呢？
前一小节的两个接口有用了，ResourceLoaderAware和ApplicationContextAware，他们都能拿到IoC容器本身呀。
public class FooBar implements ApplicationContextAware {
private ResourceLoader resourceLoader;
public void foo(String location) {
System.out.println(getResourceLoader().getResource(location).getClass());
}
public ResourceLoader getResourceLoader() {
return resourceLoader;
}
public void setApplicationContext(ApplicationContext ctx)
throws BeansException
{
this.resourceLoader = ctx;
}
}
看这配置文件不就只有一行了，方便。
<bean id="fooBar" class="...FooBar">
</bean>后记
写完这篇，基本算是把资源一部分搞懂了一点，但是最近一直在反思，这种总结的办法，可以我是确实不会用Markdown吧，每次花在编辑上的时间就非常多了。还是要想想办法解决这个问题。
