spring-core-2 Resource

2.1 Resource 接口

spring的Resource接口用于对访问底层资源的抽象.

public interface Resource extends InputStreamSource {

    boolean exists();

    boolean isOpen();

    URL getURL() throws IOException;

    File getFile() throws IOException;

    Resource createRelative(String relativePath) throws IOException;

    String getFilename();

    String getDescription();

}

public interface InputStreamSource {

    InputStream getInputStream() throws IOException;

}

Resource接口中的几个重要方法:

• getInputStream(): 查找并打开资源,并返回一个从资源读取的流, 每次调用都会返回一个新的InputStream, 因此需要调用者关闭这个流.
• exists(): 返回boolean值, 表示资源是否存在.
• isOpen(): 表示资源是否被打开, 如果为true, 表示这个InputStream不能被多次读取,即资源被打开后只能读取一次且读取后必须关闭以防止资源泄漏.除了InputStreamResource之外, 所有的常规resource实现都将返回false.
• getDescription(): 返回资源描述,常用于错误输出.
  其他方法可以获取到表示这个资源的URL或File对象.
  Resource抽象在Spring中被广泛应用, 在许多需要资源的方法签名中作为参数, Spring API(如ApplicationContext的构造函数)方法中,可用一个简单的字符串或表示指定前缀的字符串来指定资源的实现.

2.2 内置的Resource实现

spring 提供了大量的开箱即用的Resource实现.

2.2.1 UrlResource

UrlResource封装了java.net.URL, 可以通过一个URL来访问任何可以访问的对象(如文件,HTTP, FTP等). 所有的URL都有一个标准的字符串前缀,用以表示不同类型的URL, 如file:表示文件系统路径, http:表示通过http协议访问资源, ftp:表示通过FTP访问资源.
可以使用UrlResource构造函数来创建UrlResource对象, 但是很多API通常都是通过一个表示路径的字符串参数来创建它,这时将会由PropertyEditor决定创建哪种类型的UrlResource, 如果字符串中带有已知的前缀(如classpath:), 它将创建相应类型的资源, 如果未知,则会假设这是一个标准的url字符串并创建资源.

2.2.2 ClassPathResource

这个类表示可以从类路径获取到的资源.如果类路径资源存在于文件系统中(不包括jar文件和没有扩展到文件系统的), 这个Resource实现支持将其作为java.io.File来进行解析.为了解决这个问题, 各种资源实现总是支持java.net.URL.
可以通过ClassPathResource的构造函数来创建ClassPathResource对象, 但通常都是通过一个路径字符串来创建,这时PrepertyEditor将识别classpath:前缀并创建相应的ClassPathResource对象.

2.2.3 FileSystemResource

这是用于处理java.io.File的资源实现, 它支持解析File和URL.

2.2.4 ServletContextResource

这是ServletContext资源实现,用于解析web应用程序根目录中的相对路径.
它总是支持流访问和URL访问, 且仅当web应用程序存档被展开到文件系统中时可以通过java.io.File访问.

2.2.5 InputStreamResource

这是对给定InputStream的资源实现, 只有在应用中没有特定的Resource实现时才用到它. 但是尽可能避免使用它, 而用ByteArrayResource或其他基于file的Resource实现.
与其他资源实现相比, 它表示的是一个已打开的资源的描述符(即isOpen返回true). 因此如果你要多次读取它或将其保存到其他地方时,请不要使用它.

2.2.6 ByteArrayResource

这是对给定的字节数组的资源实现, 它将为给定数据生成一个ByteArrayInputStream. 它对于任何给定的字节数组中加载内容都是很有用的, 而无需使用一次性的InputStreamResource.

2.3 ResourceLoader

ResourceLoader接口定义了获取Resource对象的方法.

public interface ResourceLoader {

    Resource getResource(String location);

}

所有的ApplicationContext都扩展了ResourceLoader接口.因此所有的ApplicationContext都可以获取Resource实例.
当通过application context调用getResource()方法时, 路径字符串中不需要指定前缀, 这将返回一个与容器类型一致的资源对象.例如通过ClassPathXmlApplicationContext实现调用:

Resource template = ctx.getResource("some/resource/path/myTemplate.txt");

此时会返回ClassPathResource类型的对象.

当然, 你也可以通过指定资源前缀来返回指定类型的资源,此时无论application context是什么类型.如:

Resource template = ctx.getResource("classpath:some/resource/path/myTemplate.txt");

资源路径示例:

前缀	示例	说明
classpath:	calsspath:com/myapp/config.xml	从类路径中加载
file:	file:///data/config.xml	加载一个URL, 从文件系统加载
http:	http://myserver/logo.png	加载URL
(none)	/data/config.xml	依赖于底层的ApplicationContext

2.4 ResourceLoaderAware接口

public interface ResourceLoaderAware {

    void setResourceLoader(ResourceLoader resourceLoader);
}

实现这个接口, 便可以获取ResourecLoader引用.

2.5 资源依赖关系

如果bean本身要动态地确定和提供资源, 此时使用ResourceLoader接口来加载资源是有意义的.现在假设要根据不同的角色加载不同的模板, 如果这些模板资源是静态的,那么完全消除对ResourceLoader接口的依赖是有意义的, 且此时只要暴露这个bean所需要的Resource属性即可注入相应的资源.
注入这些资源非常简单, 我们只需要给Resource类型的属性提供一个简单的资源路径字符串即可, 此时将由一个特殊的bean,即PropertyEditor来将字符串转换为相应的资源.如:

<bean id="myBean" class="...">
    <property name="template" value="some/resource/path/myTemplate.txt"/>
</bean>

注意这个字符串没有前缀,因为容器本身就是一个资源加载器, 这个资源将会根据容器的类型被加载为相应类型的资源.
当然, 你也可以使用前缀指定特定的资源类型:

<property name="template" value="classpath:some/resource/path/myTemplate.txt">
<property name="template" value="file:///some/resource/path/myTemplate.txt"/>

2.7 ApplicationContext与资源路径

2.7.1 构造ApplicationContext

ApplicationContext的构造器可以接收一个表示资源路径的String或String数组来加载bean定义配置文件.当给定的路径没有前缀时,加载的资源类型将与ApplicationContext的类型一致.
示例:

ApplicationContext ctx = new ClassPathXmlApplicationContext("conf/appContext.xml");

此时将会从类路径中加载并创建一个ClassPathResource类型的资源.
但是如果你指定了资源前缀,则容器将会将资源加载为与前缀相匹配的类型.

2.7.2 ApplicationContext构造函数中资源路径通配符

ApplicationContext的构造器中的路径参数或以是一个简单字符串, 也可以包含一个特定前缀classpath*:, 也可以使用Ant样式的表达式.后两种都用到了通配符.
注意: 不能使用通配符来构造具体的资源, 因为一个资源对象只对应一个资源而不能对应多个.

Ant样式
示例:

/WEB-INF/*-context.xml
com/mycompany/**/applicationContext.xml
file:C:/some/path/*-context.xml
classpath:com/mycompany/**/applicationContext.xml

classpath*:前缀
当使用xml来构建容器时,路径字符串中可能用到这个前缀.

ApplicationContext ctx =
    new ClassPathXmlApplicationContext("classpath*:conf/appContext.xml");

这个前缀指定了获取所有与给定路径匹配的资源(这个工作是由ClassLoader.getResoureces(..)方法实现的), 然后合并为最终的容器定义.

这个通配符依赖于底层的ClassLoader的getResources()方法,而现在几乎所有的应用服务器都有自己的类加载器, 这在处理jar文件时可能会有所不同.检查classpath*:是否正常工作的方式是从类路径中的jar中加载一个文件, 即getClass().getClassLoader().getResoureces(someFileInsideTheJar). 使用处于不同位置的具有相同名称的文件进行测试, 如果没有返回所期望的结果, 请检查应用服务器关于类加载行为的配置.

classpath*:前缀还可以与Ant样式组合使用, 如classpath*:META-INF/*-beans.xml.它的解析机制非常简单, 先是从最后一个不包含通配符的路径中加载所有资源,然后再进行资源匹配.
当classpath*:前缀与Ant样式组合使用时,至少要有一个根目录,即如果以classpath*:*.xml这种形式时,可能不会从jar的根目录中加载文件, 而只从扩展目录的根目录中加载文件.

2.7.3 FileSystemResource说明

当FileSystemApplicationContext不是实际的ResourceLoader时,此时FileSystemResource能正确处理绝对路径和相对路径. 反之,它会将所有路径都视为相对路径, 无论它前面是否有/. 这是由于历史原因(保证向后兼容)决定的.即以下两种配置是一样的:

ApplicationContext ctx =
    new FileSystemXmlApplicationContext("conf/context.xml");

ApplicationContext ctx =
    new FileSystemXmlApplicationContext("/conf/context.xml");

如果确实需要绝对路径, 最好的方式是不对FileSystemResourec或FileSystemXmlApplication使用绝对路径, 而是使用UrlResource的file:来定义.即:

ctx.getResource("file:///some/resource/path/myTemplate.txt");

ApplicationContext ctx =
    new FileSystemXmlApplicationContext("file:///conf/context.xml");