2、springframe Resources

2. Resources

 

 

本章介绍了 Spring 如何处理资源以及如何在 Spring 中使用资源。它包括以下主题：

• Introduction

• 资源接口

• 内置资源实现

• The ResourceLoader

• ResourceLoaderAware 接口

• 资源依赖

• 应用程序上下文和资源路径

2.1. Introduction

不幸的是，Java 的标准java.net.URL类和用于各种 URL 前缀的标准处理程序不足以满足所有对低级资源的访问。例如，没有标准化的URL实现可用于访问需要从 Classpath 或相对于ServletContext获得的资源。尽管可以为专用的URL前缀注册新的处理程序(类似于现有的针对http:的前缀的处理程序)，但这通常相当复杂，并且URL接口仍然缺少某些理想的功能，例如用于检查是否存在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，必须仅读取一次，然后关闭InputStream以避免资源泄漏。对于所有常规资源实现，返回false，但InputStreamResource除外。

• getDescription()：返回此资源的描述，用于在处理资源时输出错误。这通常是标准文件名或资源的实际 URL。

其他方法可让您获得代表资源的实际URL或File对象(如果基础实现兼容并且支持该功能)。

当需要资源时，Spring 本身广泛使用Resource抽象作为许多方法签名中的参数类型。某些 Spring API 中的其他方法(例如，各种ApplicationContext实现的构造函数)采用String，其以无装饰或简单的形式用于创建适合于该上下文实现的Resource，或者通过String路径上的特殊前缀，让调用者指定必须创建并使用特定的Resource实现。

虽然Resource接口在 Spring 和 Spring 上经常使用，但在您自己的代码中单独用作通用实用工具类来访问资源实际上非常有用，即使您的代码不知道或不关心其他任何代码 Spring 的一部分。虽然这会将您的代码耦合到 Spring，但实际上仅将其耦合到这套 Util 小类，它们可以更强大地替代URL，并且可以认为等同于您将为此使用的任何其他库。

Note

Resource抽象不能代替功能。它尽可能地包装它。例如，一个UrlResource包裹一个 URL，并使用包裹的URL来完成其工作。

2.3. 内置lResource实现

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 访问资源，以及其他。

Java 代码通过显式使用UrlResource构造函数来创建UrlResource，但是在调用带有String自变量表示路径的 API 方法时，通常会隐式创建UrlResource。对于后一种情况，JavaBeans PropertyEditor最终决定要创建哪种类型的Resource。如果路径字符串包含众所周知的前缀(例如classpath:)，则会为该前缀创建一个适当的专用Resource。但是，如果无法识别前缀，则假定该字符串是标准 URL 字符串并创建UrlResource。

2.3.2. ClassPathResource

此类表示应从 Classpath 获取的资源。它使用线程上下文类加载器，给定的类加载器或给定的类来加载资源。

如果 Classpath 资源驻留在文件系统中，而不是驻留在 jar 中并且尚未(通过 servlet 引擎或任何环境将其扩展到)文件系统的 Classpath 资源不驻留在文件系统中，则此Resource实现支持以java.io.File解析。为了解决这个问题，各种Resource实现始终支持将分辨率作为java.net.URL。

Java 代码通过显式使用ClassPathResource构造函数来创建ClassPathResource，但是在调用带有String自变量表示路径的 API 方法时，通常会隐式创建ClassPathResource。对于后一种情况，JavaBeans 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 应用程序 Files 并且资源实际位于文件系统上时才允许java.io.File访问。它是在文件系统上扩展还是在文件系统上进行扩展，或者直接从 JAR 或其他类似数据库(可以想到的)访问，实际上取决于 Servlet 容器。

2.3.5. InputStreamResource

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

与其他Resource实现相反，这是一个已经打开的资源的 Descriptors。因此，它从isOpen()返回true。如果您需要将资源 Descriptors 保留在某个地方，或者需要多次读取流，请不要使用它。

2.3.6. ByteArrayResource

这是给定字节数组的Resource实现。它为给定的字节数组创建一个ByteArrayInputStream。

这对于从任何给定的字节数组加载内容而无需使用一次性InputStreamResource很有用。

2.4. 资源加载器ResourceLoader

ResourceLoader接口旨在由可以返回(即加载)Resource实例的对象实现。以下清单显示了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。类似地，它将为每个上下文返回适当的对象。

结果，您可以以适合特定应用程序上下文的方式加载资源。

另一方面，您也可以通过指定特殊的classpath:前缀来强制使用ClassPathResource，而与应用程序上下文类型无关，如下例所示：　　

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("http://myhost.com/resource/path/myTemplate.txt");

表 10.资源字符串

Prefix	Example	Explanation
classpath:	classpath:com/myapp/config.xml	从 Classpath 加载。
file:	file:///data/config.xml	从文件系统作为URL加载。另请参见FileSystemResource Caveats。
http:	http://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接口。该代码将仅耦合到资源加载接口(可以视为 Util 接口)，而不耦合到整个 Spring ApplicationContext接口。　

从 Spring 2.5 开始，您可以依靠ResourceLoader的自动装配来替代实现ResourceLoaderAware接口。现在，“传统” constructor和byType自动装配模式(如Autowiring Collaborators中所述)能够分别为构造函数参数或 setter 方法参数提供ResourceLoader类型的依赖项。为了获得更大的灵活性(包括自动装配字段和多个参数方法的能力)，请考虑使用基于注解的自动装配功能。在这种情况下，只要有问题的字段，构造函数或方法带有@Autowired注解，就将ResourceLoader自动连接到期望ResourceLoader类型的字段，构造函数参数或方法参数中。　　

2.6. 资源依赖

如果 Bean 本身将通过某种动态过程来确定并提供资源路径，那么对于 Bean 来说，使用ResourceLoader接口加载资源可能是有意义的。例如，考虑加载某种模板，其中所需的特定资源取决于用户的角色。如果资源是静态的，则有必要完全消除对ResourceLoader接口的使用，让 Bean 公开所需的Resource属性，并期望将其注入其中。

 然后注入这些属性很简单，因为所有应用程序上下文都注册并使用了特殊的 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"/>

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

2.7. 应用程序上下文和资源路径

本节介绍如何使用资源创建应用程序上下文，包括使用 XML 的快捷方式，如何使用通配符以及其他详细信息。

2.7.1. 构造应用程序上下文

应用程序上下文构造函数通常采用字符串或字符串数组作为资源的位置路径，例如构成上下文定义的 XML 文件。

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

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

Bean 定义是从 Classpath 加载的，因为使用了ClassPathResource。但是，请考虑以下示例，该示例创建FileSystemXmlApplicationContext：

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

现在，bean 定义是从文件系统位置(在这种情况下，是相对于当前工作目录)加载的。

请注意，在位置路径上使用特殊的 Classpath 前缀或标准 URL 前缀会覆盖为加载定义而创建的默认类型Resource。考虑以下示例：

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

使用FileSystemXmlApplicationContext从 Classpath 中加载 bean 定义。但是，它仍然是FileSystemXmlApplicationContext。如果随后将其用作ResourceLoader，则所有未前缀的路径仍将视为文件系统路径。

构造 ClassPathXmlApplicationContext 实例—快捷方式

ClassPathXmlApplicationContext公开了许多构造函数以启用方便的实例化。基本思想是，您只能提供一个字符串数组，该字符串数组仅包含 XML 文件本身的文件名(不包含前导路径信息)，还提供Class。 ClassPathXmlApplicationContext然后从提供的类中导出路径信息。

请考虑以下目录布局：

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

以下示例显示了如何实例化由名为services.xml和daos.xml(位于 Classpath 中)的文件中定义的 bean 组成的ClassPathXmlApplicationContext实例：

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

有关各种构造函数的详细信息，请参见ClassPathXmlApplicationContext javadoc。

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

应用程序上下文构造函数值中的资源路径可以是简单路径(如前所述)，每个路径都具有到目标Resource的一对一 Map，或者可以包含特殊的“ classpath *：”前缀或内部 Ant。样式的正则表达式(通过使用 Spring 的PathMatcherUtil 进行匹配)。后者都是有效的通配符。

这种机制的一种用途是当您需要进行组件样式的应用程序组装时。所有组件都可以将上下文定义片段“发布”到一个众所周知的位置路径，并且当使用前缀classpath*:的相同路径创建最终应用程序上下文时，所有组件片段都会被自动拾取。

请注意，此通配符特定于在应用程序上下文构造函数中使用资源路径(或在直接使用PathMatcherUtil 类层次结构时使用)，并在构造时解决。它与Resource类型本身无关。您不能使用classpath*:前缀构造实际的Resource，因为资源一次仅指向一个资源。

Ant-style Patterns

路径位置可以包含 Ant 样式的模式，如以下示例所示：

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

当路径位置包含 Ant 样式的模式时，解析程序将遵循更复杂的过程来尝试解析通配符。它为到达最后一个非通配符段的路径生成一个Resource，并从中获取 URL。如果此 URL 不是jar:URL 或特定于容器的变体(例如 WebLogic 中的zip:，WebSphere 中的wsjar等)，则从中获得java.io.File并将其用于遍历文件系统来解析通配符。对于 jar URL，解析器可以从中获取java.net.JarURLConnection或手动解析 jar URL，然后遍历 jar 文件的内容来解析通配符。

对便携性的影响

如果指定的路径已经是一个文件 URL(由于基ResourceLoader是一个文件系统，则是隐式的，或者是明确的)，则保证通配符可以完全可移植的方式工作。

如果指定的路径是 Classpath 位置，则解析器必须通过进行Classloader.getResource()调用来获取最后一个非通配符路径段 URL。由于这只是路径的一个节点(而不是末尾的文件)，因此实际上(在ClassLoader javadoc 中)未定义到底返回了哪种 URL。实际上，它始终是代表目录的java.io.File(Classpath 资源解析为文件系统位置)或某种 jar URL(Classpath 资源解析为 jar 位置)。尽管如此，此操作仍存在可移植性问题。

如果为最后一个非通配符段获取了 jar URL，则解析程序必须能够从中获取java.net.JarURLConnection或手动解析 jar URL，以便能够遍历 jar 的内容并解析通配符。这在大多数环境中确实有效，但在其他环境中则无效，因此我们强烈建议您在依赖特定环境之前，对来自 jars 的资源的通配符解析进行彻底测试。

Classpath*：前缀

构造基于 XML 的应用程序上下文时，位置字符串可以使用特殊的classpath*:前缀，如以下示例所示：

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

这个特殊的前缀指定必须获取与给定名称匹配的所有 Classpath 资源(内部，这实际上是通过调用ClassLoader.getResources(…)发生的)，然后合并以形成最终的应用程序上下文定义。

Note

通配符 Classpath 依赖于基础类加载器的getResources()方法。由于当今大多数应用程序服务器提供其自己的类加载器实现，因此行为可能有所不同，尤其是在处理 jar 文件时。检查classpath*是否有效的简单测试是使用类加载器从 ClasspathgetClass().getClassLoader().getResources("<someFileInsideTheJar>")的 jar 中加载文件。尝试对具有相同名称但位于两个不同位置的文件进行此测试。如果返回了不合适的结果，请检查应用程序服务器文档中可能影响类加载器行为的设置。

您还可以在其余的位置路径(例如classpath*:META-INF/*-beans.xml)中将classpath*:前缀与PathMatcher模式结合使用。在这种情况下，解析策略非常简单：在最后一个非通配符路径段上使用ClassLoader.getResources()调用，以获取类加载器层次结构中的所有匹配资源，然后从每个资源中分离出与上述相同的PathMatcher解析策略：用于通配符子路径。

与通配符有关的其他说明

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

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

Note

扫描 Classpath 包需要在 Classpath 中存在相应的目录条目。使用 Ant 构建 JAR 时，请勿激活 JAR 任务的仅文件开关。另外，在某些环境中，Classpath 目录可能不会基于安全策略公开-例如，在 JDK 1.7.0_45 及更高版本上的独立应用程序(要求在清单中设置“受信任的库”.请参阅http://stackoverflow.com/questions/19394570/java-jre-7u45-breaks-classloader-getresources)。

在 JDK 9 的模块路径(Jigsaw)上，Spring 的 Classpath 扫描通常可以按预期进行。强烈建议在此处将资源放入专用目录中，以避免在搜索 jar 文件根级别时遇到上述可移植性问题。

如果要搜索的根包在多个 Classpath 位置中可用，则不能保证具有classpath:资源的 Ant 样式模式会找到匹配的资源。考虑以下资源位置示例：

com/mycompany/package1/service-context.xml

现在考虑某人可能用来尝试找到该文件的 Ant 样式的路径：

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

这样的资源可能只在一个位置，但是当使用诸如前面示例的路径尝试解析它时，解析器将根据getResource("com/mycompany");返回的(第一个)URL 进行处理。如果此基本包节点存在于多个类加载器位置，则实际的最终资源可能不存在。因此，在这种情况下，您应该更喜欢使用具有相同 Ant 样式模式的classpath*:，该模式将搜索包含根包的所有 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: URL 前缀来强制使用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");