Spring 5 中文解析核心篇-IoC容器之Resource

这个章节涵盖了Spring怎样处理和在Spring中使用资源文件。包括下面主题：

• 介绍
• Resource接口
• 内建Resource实现
• ResourceLoader
• ResourceLoaderAware接口
• Resource做为依赖
• 应用上下文和Resource路径

2.1 介绍

Java的标准java.net.URL类和标准处理URL前缀变体，不幸地，对于全部访问低级资源的能力还不够。例如，这里没有须要从类路径或相关联的ServletContext获取资源使用的标准URL实现。固然也能够注册新的处理器为特定URL前缀(相似已经存在的前置处理器，例如：http:)，一般这是十分的复杂，而且URL接口仍然缺少一些功能描述，例如一种检查所指向资源是否存在的方法。

2.2 Resource接口

Spring的Resource接口意思是为抽象获取低级别资源提供更多的能力。下面清单显示了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();
}

像Resource接口定义显示这样，它拓展了InputStreamSource接口。下面清单显示InputStreamSource接口的定义：

public interface InputStreamSource {

    InputStream getInputStream() throws IOException;
}

一些Resource接口中重要的方法：

• getInputStream()：定位和打开资源而且返回从资源中读取的InputStream。每次调用都返回一个新的InputStream。咱们有责任去关闭流。
• exists()：任何一个boolean指示是否这个资源在物理路径存在。
• isOpen()：而后一个boolean指示此资源是否表明打开流的句柄。若是为true，InputStream不能被屡次读取且只能读取一次，并且须要关闭资源避免被泄露。对于全部常规资源实现，返回false，但InputStreamResource除外。
• getDescription()：返回这个资源的描述，以在使用该资源时用于错误输出。这一般是标准文件名或资源的实际URL。

其余方法容许你获取一个真实URL或FIle对象描述资源(若是底层实现是兼容和支持该功能)。

当须要资源时，Spring自身普遍地使用Resource抽象，在许多方法签名上参数类型。一些Spring API中的其余方法（例如，各类ApplicationContext实现的构造函数）采用String形式，该字符串以未经修饰或简单的形式用于建立适合该上下文实现的Resource，或者经过String路径上的特殊前缀，让调用者指定必须建立并使用特定的资源实现。

虽然Resource接口在Spring中被大量使用，可是在你本身的代码中做为一个通用的实用程序类来使用它其实是很是有用的，以便访问资源，即便你的代码不知道或不关心Spring的任何其余部分。虽然这个耦合Spring到你的代码，它仅仅耦合很是小的工具类集合，能够用做URL的更强大替代，而且能够认为与你将用于此目的的任何其余库等效。

Resource抽象不能替换功能。它尽量地包装它。例如， UrlResource包装URL和使用包装的URL去工做。

2.3 内建的Resource实现

Spring包含下面的Resource实现：

• UrlResource
• ClassPathResource
• FileSystemResource
• ServletContextResource
• InputStreamResource
• ByteArrayResource

2.3.1 UrlResource

UrlResource包装了java.net.URL，可用于访问一般能够经过URL访问的任何对象，例如文件，HTTP目标、FTP目标等。全部URL有一个标准化的String表示，所以使用适当的标准化前缀来指示一种URL类型。这包括获取文件系统路径file:、经过HTTP协议获取资源http:、经过FTP获取资源ftp:等等。

UrlResource是由Java代码经过显式使用UrlResource构造函数建立的，但一般在调用带有String参数表示路径的API方法时隐式建立。对于后一种状况，JavaBean PropertyEditor最终决定哪种Resource类型被建立。若是字符串包含咱们所知的前缀(例如 classpath:)，它建立一个适当的指定前缀的Resource。然而，若是不能识别前缀，假设字符串是标准的URL字符串并建立一个UrlResource。

2.3.2 ClassPathResource

这个类表明一个可以从类路径获取的资源。它使用线程上下文类加载器、给定的类加载器或给定的类来加载资源。

这个资源实现支持将解析做为java.io.File。若是类路径资源驻留在文件系统中，而不是类路径资源驻留在jar中，而且没有(由servlet引擎或其余环境)扩展到文件系统。为了解决这个问题，各类Resource实现始终支持将解析做为java.net.URL进行。

当你采用一个String参数描述路径调用API方法时，ClassPathResource是经过显示使用ClassPathResource构造函数经过Java代码建立，可是一般隐式地被建立。对于后一种状况，javabean PropertyEditor识别在字符串路径中指定前缀classpath:而且在这个场景中建立一个ClassPathResource。

2.3.3 FileSystemResource

这是java.io.File和java.nio.file.Path句柄的Resource实现。它支持解析做为File和URL。

2.3.4 ServletContextResource

这是ServletContext资源的Resource实现，它解释相关Web应用程序根目录中的相对路径。

它始终支持流访问和URL访问，但仅在扩展Web应用程序实现被扩展和资源在实际文件系统上时才容许java.io.File访问。它是在文件系统上扩展仍是直接扩展，或者直接从JAR或其余相似数据库（能够想到的）中访问，实际上取决于Servlet容器。

2.3.5 InputStreamResource

InputStreamResource是一个给定InputStream的Resource实现。仅当没有特定的资源实现时才应使用它。特别是，在可能的状况下，最好选择ByteArrayResource或任何基于文件的Resource实现。

对比其余的Resource实现，这是一个对于已经打开的资源的描述。所以，isOpen()方法返回true。若是你须要将资源描述符保留在某个地方或须要屡次读取流，请不要使用它。

2.3.6 ByteArrayResource

这是一个给定byte数组的Resource实现。它为给定byte数组建立一个ByteArrayInputStream。

这对于从任何给定的字节数组加载内容颇有用，而没必要求助于一次性InputStreamResource。

参考代码： com.liyong.ioccontainer.starter.ResourceIocContainer

2.4 ResourceLoader

ResourceLoader接口是由能够返回(即加载)资源实例的对象实现的。下面清单显示ResourceLoader定义：

public interface ResourceLoader {

    Resource getResource(String location);
}

全部的应用上下文实现ResourceLoader接口。所以，全部应用上下文可使用去获取Resource实例。

当你在指定应用上下文上调用getResource()，而且定义路径没有指定前缀，你能够获取特定应用上下文中适合的Resource类型。例如，假定针对ClassPathXmlApplicationContext实例执行了如下代码片断：

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

针对ClassPathXmlApplicationContext，这个代码返回一个ClassPathResource实例。针对FileSystemXmlApplicationContext若是相同方法被执行，它将返回FileSystemResource。对于WebApplicationContext，它将返回一个ServletContextResource。它将相似地为每个上下文返回适合的对象。

最后，你能够以适合特定应用程序上下文的方式加载资源。

另外一方面，你也能够强制使用ClassPathResource，无论应用上下文类型，经过指定classpath:前缀，相似下面例子显示：

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

相似地，你能够经过指定标准的java.net.URL前缀强制使用UrlResource。下面两个例子使用file和http前缀：

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

Resource template = ctx.getResource("https://myhost.com/resource/path/myTemplate.txt");

下面表格总结对于转换String对象到Resource对象的策略 ：

Prefix	Example	Explanation
classpath:	classpath:com/myapp/config.xml	类路径加载
file:	file:///data/config.xml	做为URL资源从文件系统加载 FileSystemResourceCaveats.
http:	https://myserver/logo.png	做为URL加载
(none)	/data/config.xml	依赖底层ApplicationContext

2.5 ResourceLoaderAware接口

ResourceLoaderAware接口是一个特殊的回调接口，它表示但愿使用ResourceLoader引用提供的组件。下面清单显示ResourceLoaderAware接口定义：

public interface ResourceLoaderAware {

   void setResourceLoader(ResourceLoader resourceLoader);
}

当一个类实现ResourceLoaderAware而且被部署到应用上下文中(做为Spring管理的bean)，它应用上下文做为ResourceLoaderAware被识别。应用上下文调用setResourceLoader(ResourceLoader)，应用自身做为参数(记住，Spring中的全部应用程序上下文都实现ResourceLoader接口)。

由于ApplicationContext是ResourceLoader，bean也能够实现ApplicationContextAware接口而且使用使用应用上下文直接地加载资源。可是，一般，若是须要的话，最好使用专门的ResourceLoader接口。该代码将仅耦合到资源加载接口（能够视为实用程序接口），而不耦合到整个Spring ApplicationContext接口。

在应用中的组件，你也能够依赖注入ResourceLoader做为实现ResourceLoaderAware接口替代方案。“传统”构造函数和byType自动装配模式（如“自动装配协做器”中所述）可以分别为构造函数参数或setter方法参数提供ResourceLoader。为了更大的灵活性(包含自动装配字段和多参数方法)，考虑使用基于注解的特性。在这种状况下，ResourceLoader自动装配到字段、构造函数或方法参数、字段、构造函数或方法携带有@Autowired注解，就会指望ResourceLoader类型。更多消息，查看@Autowired使用。

2.6 依赖Resources

若是Bean自己将经过某种动态过程来肯定和提供资源路径，那么对于Bean来讲，使用ResourceLoader接口加载资源多是有意义的。例如，考虑加载某种模板，其中所需的特定资源取决于用户的角色。若是资源是静态的，那么彻底消除ResourceLoader接口的使用是有意义的，让bean公开它须要的资源属性，并指望将它们注入到bean中。

而后注入这些属性的麻烦之处在于，全部应用程序上下文都注册并使用了特殊的JavaBeans PropertyEditor，它能够将String路径转换为Resource对象。若是myBean有一个Resource类型模版属性，它能够为资源配置一个简单的字符串，相似下面例子显示：

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

注意，资源路径没有前缀。所以，因为应用程序上下文自己将被用做ResourceLoader，因此资源自己是经过ClassPathResource、FileSystemResource或ServletContextResource加载的，这取决于上下文的确切类型。

若是你须要强制指定使用的Resource类型，你可使用前缀。下面两个例子显示怎样去强制使用ClassPathResource和UrlResource(后面这个例子使用文件系统获取)：

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

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

参考代码： com.liyong.ioccontainer.starter.Resource2IocContainer

2.7 应用上下文和资源路径

这个章节涵盖怎样建立应用上下文与资源，包括与XML一块儿使用的快捷方式，如何使用通配符以及其余详细信息

2.7.1 构造应用上下文

应用上下文构造一般地采用字符串或资源位置路径字符串，例如构成上下文定义的XML文件。

当位置路径没有前缀时，从该路径构建并用于加载Bean定义的特定Resource类型取决于特定应用程序上下文，而且适用于该特定应用程序上下文。例如，考虑下面例子，建立一个ClassPathXmlApplicationContext：

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

bean定义从类路径被加载，由于ClassPathResource被使用。然而，考虑下面例子，建立一个FileSystemXmlApplicationContext：

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

bean定义从文件系统位置被加载(在这个场景中，相对于当前工做目录)。

注意，使用位置路径上的特殊类路径前缀或标准URL前缀会覆盖为加载定义而建立的默认资源类型。

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

使用FileSystemXmlApplicationContext从类路径加载bean定义。然而，它仍然是一个FileSystemXmlApplicationContext。若是随后将其用做ResourceLoader，则任何无前缀的路径仍将视为文件系统路径。

构造ClassPathXmlApplicationContext实例-快捷方式

ClassPathXmlApplicationContext暴露许多构造方法去实例化。基本思想是，你只提供一个字符串数组，该字符串数组仅包含XML文件本自身的文件名（不包含前导路径信息），而且还提供一个Class。而后，ClassPathXmlApplicationContext从提供的类中获取路径信息。

考虑下面路径布局：

com/
  foo/
    services.xml
    daos.xml
    MessengerService.class

如下示例显示如何实例化由在名为service.xml和daos.xml（位于类路径中）的文件中定义的bean组成的ClassPathXmlApplicationContext实例：

ApplicationContext ctx = new ClassPathXmlApplicationContext(
    new String[] {"services.xml", "daos.xml"}, MessengerService.class);

查看ClassPathXmlApplicationContext详细javadock的各类构造。

2.7.2 应用程序上下文构造函数资源路径中的通配符

应用程序上下文构造函数值中的资源路径能够是简单路径（如先前所示），每一个路径都具备到目标资源的一对一映射，或者能够包含特殊的“classpath*:”前缀或内部Ant常规样式的正则表达式（经过使用Spring的PathMatcher进行匹配）。后者都是有效的通配符。

这种机制使用之一是当你须要组件风格封装应用时。全部组件均可以将上下文定义片断“发布”到一个已知的位置路径，而且，当使用以classpath*:做为前缀的相同路径建立最终的应用程序上下文时，全部组件片断都会被自动获取。

注意，这种通配符是特定于在应用程序上下文构造函数中使用资源路径的(或者当你直接使用PathMatcher程序类层次结构时)，并在构造时解析。它与资源类型自己无关。你不能使用classpath*:前缀来构造实际的资源，由于一个资源每次只指向一个资源。

Ant风格模式

路径位置能够包含Ant风格模式，相似下面例子显示：

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

当路径位置包含一个Ant风格模式时，解析器容许更复杂程序尝试去解析通配符。它为最后一个非通配符段的路径生成一个资源，并从中得到一个URL。若是这个URL不是jar:URL或包含特定变体(例如，在WebLogic中的zip:、在WebSphere中的wsjar等等)，从中得到一个java.io.File，并经过遍历文件系统来解析通配符。对于jar URL，解析器能够从中获取java.net.Jar URLConnection，也能够手动解析jar URL，而后遍历jar文件的内容以解析通配符。

影响可移植性

若是指定的路径已是一个文件URL（因为基本ResourceLoader是一个文件系统，因此它是隐式的，或者是显式的），则保证通配符能够彻底可移植的方式工做。

若是指定的路径是类路径位置，则解析器必须经过调用Classloader.getResource()得到最后的非通配符路径段URL。因为这只是路径的一个节点（而不是末尾的文件），所以实际上（在ClassLoader javadoc中）未定义确切返回的是哪一种URL。。在实践中，它老是一个java.io.File描述目录(类路径资源解析为文件系统的位置)或一个一些种类(类路径资源解析为jar位置)jar URL。尽管如此，此操做仍存在可移植性问题。

若是为最后一个非通配符段获取了jar URL，则解析器必须可以从中获取java.net.Jar URLConnection或手动解析jar URL，以便可以遍历jar的内容并解析通配符。这在大多数环境中确实有效，但在其余环境中则无效，所以咱们强烈建议在依赖特定环境以前，对来自jars的资源的通配符解析进行完全测试。

classpath*:前缀

当构造基于XML应用上下文时，位置字符串可能使用指定的classpath*:前缀，相似下面例子显示：

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

这个特殊的前缀指定必须获取与给定名称匹配的全部类路径资源（内部，其实是经过调用ClassLoader.getResources(…)发生的），而后合并造成最终的应用程序上下文定义。

通配符类路径依赖类加载器底层的 getResources()方法。因为当今大多数应用程序服务器都提供本身的类加载器实现，所以行为可能有所不一样，尤为是在处理jar文件时。检查 classpath *是否有效的一个简单测试是使用 classloader从 classpath的jar中加载文件：

getClass().getClassLoader().getResources("<someFileInsideTheJar>")。尝试对具备相同名称但位于两个不一样位置的文件进行此测试。若是返回了不合适的结果，请检查应用程序服务器文档中可能会影响类加载器行为的设置。

你能够在其他的位置路径中将classpath*:前缀与PathMatcher模式结合使用(例如，classpath*:META-INF/*-beans.xml)，在这个场景中，解析策略是至关地简单：在最后一个非通配符路径段上使用ClassLoader.getResources()调用，以获取类加载器层次结构中的全部匹配资源，而后在每一个资源以外，对通配符子路径使用前面所述的相同PathMatcher解析策略。

通配符相关的其余注意

注意，当与ant样式模式结合使用时，除非实际目标文件位于文件系统中，不然classpath*:只能在模式启动以前可靠地与至少一个根目录一块儿工做。这意味着诸如classpath * : * .xml之类的模式可能不会从jar文件的根目录检索文件，而只会从扩展目录的根目录检索文件。

Spring检索类路径条目的能力源于JDK的ClassLoader.getResources()方法，该方法返回文件系统中的空字符串位置（表示可能要搜索的根）。Spring还会评估jar文件中的URLClassLoader运行时配置和java.class.path清单，但这不能保证会致使可移植行为。

类路径包扫描要求在类路径中对于目录条目存在。使用Ant构建JAR时，请勿激活JAR任务的文件开关。另外，在某些环境中，基于安全策略，类路径目录可能不会公开。例如，JDK 1.7.0_45及更高版本上的独立应用程序(这须要在清单中设置“受信任的库”)查看 https://stackoverflow.com/que...

在JDK9的模块路径上，Spring的类路径扫描一般能够正常进行。强烈建议在此处将资源放入专用目录，以免在搜索jar文件根目录级别时出现上述可移植性问题。

具备classpath:的Ant样式模式：若是要搜索的根包在多个类路径位置可用，不能保证找到匹配的资源。考虑下面资源为主例子：

com/mycompany/package1/service-context.xml

如今考虑一个ant样式的路径，有人可能会使用它来尝试查找该文件Ant格式路径

classpath:com/mycompany/**/service-context.xml

这些资源可能只在一个位置，可是当使用诸如前面示例的路径尝试对其进行解析时，解析器将处理getResource( "com/mycompany”)返回的(第一个)URL。若是这个基础包节点在多个类加载器路径中存在，实际的最终资源可能不存在。所以，在这种状况下，你应该首选使用具备相同Ant样式模式的classpath *：，该模式将搜索包含根包的全部类路径位置。

2.7.3 FileSystemResource注意事项

未附加到FileSystemApplicationContext的FileSystemResource（即，当FileSystemApplicationContext不是实际的ResourceLoader时）将按你指望的方式处理绝对路径和相对路径。相对路径是相对于当前工做目录的，而绝对路径是相对于文件系统的根的。

可是，出于向后兼容性（历史）的缘由，当FileSystemApplicationContext是ResourceLoader时，状况会发生变化。FileSystemApplicationContext强制全部附加的FileSystemResource实例将全部位置路径视为相对路径，无论它们是否以正斜杠开头。在实践中，这意味着如下示例是等效的：

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

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

下面例子也是等效的(即便让它们有所不一样是有意义的，由于一种状况是相对的，另外一种状况是绝对的)：

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

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

在实践中，若是你须要文件系统绝对路径，你须要避免将绝对路与FileSystemResource或FileSystemXmlApplicationContext一块儿使用，而且强制经过使用file:前缀的UrlResource。下面例子显示怎样使用：

// actual context type doesn't matter, the Resource will always be UrlResource
ctx.getResource("file:///some/resource/path/myTemplate.txt");

// force this FileSystemXmlApplicationContext to load its definition via a UrlResource
ApplicationContext ctx =
    new FileSystemXmlApplicationContext("file:///conf/context.xml");

做者

我的从事金融行业，就任过易极付、思建科技、某网约车平台等重庆一流技术团队，目前就任于某银行负责统一支付系统建设。自身对金融行业有强烈的爱好。同时也实践大数据、数据存储、自动化集成和部署、分布式微服务、响应式编程、人工智能等领域。同时也热衷于技术分享创立公众号和博客站点对知识体系进行分享。关注公众号： 青年IT男 获取最新技术文章推送！

博客地址： http://youngitman.tech

CSDN： https://blog.csdn.net/liyong1...

微信公众号：

技术交流群：