资源

简介

Java 的标准 java.net.URL 类和各种 URL 前缀的标准处理器，不幸的是，对于所有对低级资源的访问来说，仍然不够充分。例如，没有标准化的 URL 实现可以用于访问需要从类路径或相对于 ServletContext 获取的资源。虽然可以为专门的 URL 前缀注册新的处理器（类似于 http: 等现有前缀的处理器），但这通常相当复杂，而且 URL 接口仍然缺少一些所需的功能，例如检查所指向资源是否存在的方法。

Resource 接口

Spring 的 Resource 接口位于 org.springframework.core.io. 包中，旨在成为一个更强大的接口，用于抽象对低级资源的访问。以下清单概述了 Resource 接口。有关更多详细信息，请参阅 Resource javadoc。

public interface Resource extends InputStreamSource {

	boolean exists();

	boolean isReadable();

	boolean isOpen();

	boolean isFile();

	URL getURL() throws IOException;

	URI getURI() throws IOException;

	File getFile() throws IOException;

	ReadableByteChannel readableChannel() throws IOException;

	long contentLength() throws IOException;

	long lastModified() 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 不能多次读取，并且必须只读取一次然后关闭以避免资源泄漏。除了 InputStreamResource 之外，所有常见的资源实现都返回 false。

  • getDescription(): 返回此资源的描述，用于处理资源时的错误输出。这通常是完全限定的文件名或资源的实际 URL。

其他方法允许您获取表示资源的实际 URL 或 File 对象（如果底层实现兼容并支持该功能）。

Resource 接口的一些实现也实现了扩展的 WritableResource 接口，用于支持写入的资源。

Spring 本身广泛使用 Resource 抽象，在许多需要资源的方法签名中将其作为参数类型。一些 Spring API 中的其他方法（例如各种 ApplicationContext 实现的构造函数）接受一个 String，该 String 以未修饰或简单形式用于创建适合该上下文实现的 Resource，或者通过 String 路径上的特殊前缀，允许调用者指定必须创建和使用特定的 Resource 实现。

虽然 Resource 接口在 Spring 中被大量使用，但它本身作为通用工具类在您自己的代码中访问资源也非常方便，即使您的代码不了解或不关心 Spring 的任何其他部分。虽然这会将您的代码与 Spring 耦合，但它实际上只将其与这组小的工具类耦合，这些工具类可以作为 URL 的更强大的替代品，并且可以被视为与您用于此目的的任何其他库等效。

Resource 抽象不取代功能。它在可能的情况下对其进行包装。例如，UrlResource 包装一个 URL 并使用包装的 URL 来完成其工作。

内置 Resource 实现

Spring 包含几个内置的 Resource 实现：

有关 Spring 中可用 Resource 实现的完整列表，请查阅 Resource javadoc 的“所有已知实现类”部分。

UrlResource

UrlResource 包装一个 java.net.URL，可用于访问通常通过 URL 访问的任何对象，例如文件、HTTPS 目标、FTP 目标等。所有 URL 都具有标准化的 String 表示形式，因此使用适当的标准化前缀来区分不同的 URL 类型。这包括用于访问文件系统路径的 file:、用于通过 HTTPS 协议访问资源的 https:、用于通过 FTP 访问资源的 ftp: 等。

UrlResource 通过 Java 代码显式使用 UrlResource 构造函数创建，但通常在您调用接受表示路径的 String 参数的 API 方法时隐式创建。对于后一种情况，JavaBeans PropertyEditor 最终决定要创建哪种类型的 Resource。如果路径字符串包含一个众所周知的（对属性编辑器而言）前缀（例如 classpath:），它会为该前缀创建一个适当的专门 Resource。但是，如果它不识别该前缀，它会假定该字符串是标准 URL 字符串并创建 UrlResource。

ClassPathResource

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

此 Resource 实现支持解析为 java.io.File，如果类路径资源位于文件系统中，但不支持位于 jar 中且尚未展开（由 servlet 引擎或任何环境）到文件系统的类路径资源。为了解决这个问题，各种 Resource 实现始终支持解析为 java.net.URL。

ClassPathResource 通过 Java 代码显式使用 ClassPathResource 构造函数创建，但通常在您调用接受表示路径的 String 参数的 API 方法时隐式创建。对于后一种情况，JavaBeans PropertyEditor 会识别字符串路径上的特殊前缀 classpath:，并在这种情况下创建 ClassPathResource。

FileSystemResource

这是 java.io.File 句柄的 Resource 实现。它还支持 java.nio.file.Path 句柄，应用 Spring 的标准基于字符串的路径转换，但通过 java.nio.file.Files API 执行所有操作。对于纯 java.nio.path.Path 基于支持，请改用 PathResource。FileSystemResource 支持解析为 File 和 URL。

PathResource

这是 java.nio.file.Path 句柄的 Resource 实现，通过 Path API 执行所有操作和转换。它支持解析为 File 和 URL，并且还实现了扩展的 WritableResource 接口。PathResource 实际上是 FileSystemResource 的纯 java.nio.path.Path 基于替代方案，具有不同的 createRelative 行为。

ServletContextResource

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

它始终支持流访问和 URL 访问，但仅当 Web 应用程序归档已展开且资源物理上位于文件系统上时才允许 java.io.File 访问。它是否展开并在文件系统上，或者直接从 JAR 或其他地方（例如数据库，这是可以想象的）访问，实际上取决于 Servlet 容器。

InputStreamResource

InputStreamResource 是给定 InputStream 的 Resource 实现。它只应在没有特定 Resource 实现适用时使用。特别是，尽可能优先使用 ByteArrayResource 或任何基于文件的 Resource 实现。

与其他 Resource 实现不同，这是一个已打开资源的描述符。因此，它从 isOpen() 返回 true。如果您需要将资源描述符保存在某处，或者需要多次读取流，请勿使用它。

ByteArrayResource

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

它对于从任何给定字节数组加载内容很有用，而无需诉诸一次性 InputStreamResource。

ResourceLoader 接口

ResourceLoader 接口旨在由可以返回（即加载）Resource 实例的对象实现。以下清单显示了 ResourceLoader 接口定义：

public interface ResourceLoader {

	Resource getResource(String location);

	ClassLoader getClassLoader();
}

所有应用程序上下文都实现了 ResourceLoader 接口。因此，所有应用程序上下文都可以用于获取 Resource 实例。

当您在特定应用程序上下文上调用 getResource()，并且指定的位置路径没有特定前缀时，您会获得一个适合该特定应用程序上下文的 Resource 类型。例如，假设以下代码片段针对 ClassPathXmlApplicationContext 实例运行：

  • Java

  • Kotlin

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

对于 ClassPathXmlApplicationContext，该代码返回一个 ClassPathResource。如果相同的方法针对 FileSystemXmlApplicationContext 实例运行，它将返回一个 FileSystemResource。对于 WebApplicationContext，它将返回一个 ServletContextResource。它也会为每个上下文返回适当的对象。

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

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

  • Java

  • Kotlin

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

同样，您可以通过指定任何标准 java.net.URL 前缀来强制使用 UrlResource。以下示例使用 file 和 https 前缀：

  • Java

  • Kotlin

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

  • Java

  • Kotlin

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

下表总结了将 String 对象转换为 Resource 对象的策略：

Table 1. 资源字符串
前缀 示例 解释

classpath:

classpath:com/myapp/config.xml

从类路径加载。

file:

file:///data/config.xml

作为 URL 从文件系统加载。另请参见 FileSystemResource 注意事项。

https:

https://myserver/logo.png

作为 URL 加载。

(无)

/data/config.xml

取决于底层 ApplicationContext。

ResourcePatternResolver 接口

ResourcePatternResolver 接口是 ResourceLoader 接口的扩展，它定义了将位置模式（例如，Ant 风格的路径模式）解析为 Resource 对象的策略。

public interface ResourcePatternResolver extends ResourceLoader {

	String CLASSPATH_ALL_URL_PREFIX = "classpath*:";

	Resource[] getResources(String locationPattern) throws IOException;
}

如上所示，此接口还定义了一个特殊的 classpath*: 资源前缀，用于从类路径中匹配所有资源。请注意，在这种情况下，资源位置预计是没有占位符的路径 —— 例如，classpath*:/config/beans.xml。类路径中的 JAR 文件或不同目录可以包含多个具有相同路径和相同名称的文件。有关 classpath*: 资源前缀的通配符支持的更多详细信息，请参阅 应用程序上下文构造函数资源路径中的通配符 及其子节。

传入的 ResourceLoader（例如，通过 ResourceLoaderAware 语义提供的一个）可以检查它是否也实现了这个扩展接口。

PathMatchingResourcePatternResolver 是一个独立的实现，可以在 ApplicationContext 之外使用，并且也由 ResourceArrayPropertyEditor 用于填充 Resource[] Bean 属性。PathMatchingResourcePatternResolver 能够将指定的资源位置路径解析为一个或多个匹配的 Resource 对象。源路径可以是一个简单的路径，与目标 Resource 具有一对一的映射，或者可以包含特殊的 classpath*: 前缀和/或内部 Ant 风格的正则表达式（使用 Spring 的 org.springframework.util.AntPathMatcher 工具进行匹配）。后两者都是有效的通配符。

任何标准 ApplicationContext 中的默认 ResourceLoader 实际上是 PathMatchingResourcePatternResolver 的一个实例，它实现了 ResourcePatternResolver 接口。ApplicationContext 实例本身也实现了 ResourcePatternResolver 接口并委托给默认的 PathMatchingResourcePatternResolver。

ResourceLoaderAware 接口

ResourceLoaderAware 接口是一个特殊的 callback 接口，用于标识期望提供 ResourceLoader 引用的组件。以下清单显示了 ResourceLoaderAware 接口的定义：

public interface ResourceLoaderAware {

	void setResourceLoader(ResourceLoader resourceLoader);
}

当一个类实现 ResourceLoaderAware 并部署到应用程序上下文（作为 Spring 管理的 Bean）时，它被应用程序上下文识别为 ResourceLoaderAware。然后，应用程序上下文调用 setResourceLoader(ResourceLoader)，将自身作为参数提供（请记住，Spring 中的所有应用程序上下文都实现了 ResourceLoader 接口）。

由于 ApplicationContext 是一个 ResourceLoader，因此 Bean 也可以实现 ApplicationContextAware 接口并直接使用提供的应用程序上下文来加载资源。但是，通常情况下，如果只需要 ResourceLoader 接口，最好使用专门的 ResourceLoader 接口。代码将仅与资源加载接口（可以视为实用程序接口）耦合，而不是与整个 Spring ApplicationContext 接口耦合。

在应用程序组件中，您也可以依赖 ResourceLoader 的自动装配作为实现 ResourceLoaderAware 接口的替代方案。传统 的 constructor 和 byType 自动装配模式（如 自动装配协作者 中所述）能够分别为构造函数参数或 setter 方法参数提供 ResourceLoader。为了获得更大的灵活性（包括自动装配字段和多个参数方法的能力），请考虑使用基于注解的自动装配功能。在这种情况下，ResourceLoader 会自动装配到期望 ResourceLoader 类型的字段、构造函数参数或方法参数中，只要该字段、构造函数或方法带有 @Autowired 注解。有关更多信息，请参阅 使用 @Autowired。

要为包含通配符或使用特殊 classpath*: 资源前缀的资源路径加载一个或多个 Resource 对象，请考虑将 ResourcePatternResolver 的实例自动装配到您的应用程序组件中，而不是 ResourceLoader。

作为依赖项的资源

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

使这些属性的注入变得轻而易举的原因是，所有应用程序上下文都注册并使用一个特殊的 JavaBeans PropertyEditor，它可以将 String 路径转换为 Resource 对象。例如，以下 MyBean 类具有 Resource 类型的 template 属性。

  • Java

  • Kotlin

package example;

public class MyBean {

	private Resource template;

	public setTemplate(Resource template) {
		this.template = template;
	}

	// ...
}
class MyBean(var template: Resource)

在 XML 配置文件中，template 属性可以用一个简单的字符串配置该资源，如以下示例所示：

<bean id="myBean" class="example.MyBean">
	<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"/>

如果 MyBean 类被重构以用于注解驱动的配置，myTemplate.txt 的路径可以存储在一个名为 template.path 的键下 —— 例如，在一个可供 Spring Environment 使用的属性文件中（参见 环境抽象）。然后可以通过 @Value 注解使用属性占位符引用模板路径（参见 使用 @Value）。Spring 将检索模板路径的值作为字符串，一个特殊的 PropertyEditor 将把字符串转换为 Resource 对象，注入到 MyBean 构造函数中。以下示例演示了如何实现这一点。

  • Java

  • Kotlin

@Component
public class MyBean {

	private final Resource template;

	public MyBean(@Value("${template.path}") Resource template) {
		this.template = template;
	}

	// ...
}
@Component
class MyBean(@Value("\${template.path}") private val template: Resource)

如果我们想支持在类路径中多个位置（例如，类路径中的多个 jar 包）的相同路径下发现的多个模板，我们可以使用特殊的 classpath*: 前缀和通配符来定义 templates.path 键为 classpath*:/config/templates/*.txt。如果我们将 MyBean 类重新定义如下，Spring 会将模板路径模式转换为 Resource 对象数组，这些对象可以注入到 MyBean 构造函数中。

  • Java

  • Kotlin

@Component
public class MyBean {

	private final Resource[] templates;

	public MyBean(@Value("${templates.path}") Resource[] templates) {
		this.templates = templates;
	}

	// ...
}
@Component
class MyBean(@Value("\${templates.path}") private val templates: Resource[])

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

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

构建应用程序上下文

应用程序上下文构造函数（对于特定的应用程序上下文类型）通常接受一个字符串或字符串数组作为资源的定位路径，例如构成上下文定义的 XML 文件。

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

  • Java

  • Kotlin

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

Bean 定义从类路径加载，因为使用了 ClassPathResource。但是，考虑以下示例，它创建了一个 FileSystemXmlApplicationContext：

  • Java

  • Kotlin

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

现在 Bean 定义从文件系统位置加载（在本例中，相对于当前工作目录）。

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

  • Java

  • Kotlin

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

使用 FileSystemXmlApplicationContext 从类路径加载 Bean 定义。但是，它仍然是一个 FileSystemXmlApplicationContext。如果它随后用作 ResourceLoader，则任何无前缀路径仍被视为文件系统路径。

构建 ClassPathXmlApplicationContext 实例 —— 快捷方式

ClassPathXmlApplicationContext 暴露了许多构造函数以方便实例化。基本思想是您只需提供一个字符串数组，其中只包含 XML 文件本身的名称（不带前导路径信息），并且还提供一个 Class。然后，ClassPathXmlApplicationContext 从提供的类派生路径信息。

考虑以下目录布局：

com/ example/ services.xml repositories.xml MessengerService.class

以下示例显示了如何实例化由 services.xml 和 repositories.xml 文件中定义的 Bean 组成的 ClassPathXmlApplicationContext 实例（这些文件在类路径中）：

  • Java

  • Kotlin

ApplicationContext ctx = new ClassPathXmlApplicationContext(
	new String[] {"services.xml", "repositories.xml"}, MessengerService.class);
val ctx = ClassPathXmlApplicationContext(arrayOf("services.xml", "repositories.xml"), MessengerService::class.java)

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

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

应用程序上下文构造函数值中的资源路径可以是简单路径（如前所示），每个路径与目标 Resource 具有一对一映射，或者，可以包含特殊的 classpath*: 前缀或内部 Ant 风格模式（通过使用 Spring 的 PathMatcher 工具进行匹配）。后两者都是有效的通配符。

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

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

Ant 风格模式

路径位置可以包含 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 文件的内容以解析通配符。

可移植性影响

如果指定的路径已经是 file URL（无论是隐式因为基础 ResourceLoader 是文件系统的一个，还是显式），则通配符保证以完全可移植的方式工作。

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

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

classpath*: 前缀

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

  • Java

  • Kotlin

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

此特殊前缀指定必须获取所有与给定名称匹配的类路径资源（在内部，这基本上是通过调用 ClassLoader.getResources(…​) 来实现的），然后合并以形成最终的应用程序上下文定义。

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

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

与通配符相关的其他注意事项

请注意，classpath*: 与 Ant 风格模式结合使用时，只有在模式开始之前至少有一个根目录的情况下才能可靠工作，除非实际目标文件位于文件系统中。这意味着像 classpath*:*.xml 这样的模式可能无法从 jar 文件的根目录中检索文件，而只能从展开的目录的根目录中检索。

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

类路径包的扫描需要类路径中存在相应的目录条目。当您使用 Ant 构建 JAR 时，请勿激活 JAR 任务的 files-only 开关。此外，在某些环境中，类路径目录可能不会根据安全策略暴露 —— 例如，JDK 1.7.0_45 及更高版本上的独立应用程序（这要求在您的清单中设置“Trusted-Library”。请参阅 https://stackoverflow.com/questions/19394570/java-jre-7u45-breaks-classloader-getresources）。在模块路径（Java 模块系统）上，Spring 的类路径扫描通常按预期工作。在这里，也将资源放入专用目录中是强烈推荐的，避免了前面提到的搜索 jar 文件根级别的可移植性问题。

如果根包在多个类路径位置可用，则带有 classpath: 资源的 Ant 风格模式不保证能找到匹配的资源。考虑以下资源位置示例：

com/mycompany/package1/service-context.xml

现在考虑某人可能用来尝试查找该文件的 Ant 风格路径：

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

这样的资源可能只存在于类路径中的一个位置，但是当使用像前面示例这样的路径尝试解析它时，解析器会从 getResource("com/mycompany"); 返回的（第一个）URL 开始工作。如果此基本包节点存在于多个 ClassLoader 位置，则所需的资源可能不存在于找到的第一个位置。因此，在这种情况下，您应该优先使用带有相同 Ant 风格模式的 classpath*:，它会搜索包含 com.mycompany 基本包的所有类路径位置：classpath*:com/mycompany/**/service-context.xml。

FileSystemResource 注意事项

未附加到 FileSystemApplicationContext 的 FileSystemResource（即，当 FileSystemApplicationContext 不是实际的 ResourceLoader 时）会按预期处理绝对路径和相对路径。相对路径相对于当前工作目录，而绝对路径相对于文件系统根目录。

然而，出于向后兼容性（历史）原因，当 FileSystemApplicationContext 是 ResourceLoader 时，这会发生变化。FileSystemApplicationContext 强制所有附加的 FileSystemResource 实例将所有位置路径视为相对路径，无论它们是否以斜杠开头。实际上，这意味着以下示例是等效的：

  • Java

  • Kotlin

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

  • Java

  • Kotlin

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

以下示例也是等效的（尽管它们应该有所不同，因为一个情况是相对的，另一个是绝对的）：

  • Java

  • Kotlin

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

  • Java

  • Kotlin

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

实际上，如果您需要真正的绝对文件系统路径，则应避免使用 FileSystemResource 或 FileSystemXmlApplicationContext 的绝对路径，并通过使用 file: URL 前缀强制使用 UrlResource。以下示例显示了如何执行此操作：

  • Java

  • Kotlin

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

  • Java

  • Kotlin

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