此版本仍在开发中,尚未被视为稳定版本。对于最新的稳定版本,请使用 Spring Framework 6.2.0! |
资源
本章介绍了 Spring 如何处理资源以及如何使用 Spring。它包括以下主题:
介绍
Java 的标准java.net.URL
类和标准处理程序,用于各种 URL 前缀,
不幸的是,对于所有对低级资源的访问来说,这还不够。为
示例,则没有标准化的URL
可用于访问
需要从 Classpath 获取的 Resource 或相对于ServletContext
.虽然可以为 specialized 注册新的处理程序URL
前缀(类似于http:
),这通常是
相当复杂,而URL
界面仍然缺乏一些理想的功能,
例如,用于检查所指向的资源是否存在的方法。
这Resource
接口
Spring的Resource
界面位于org.springframework.core.io.
package 是
旨在成为对低级资源的抽象访问的更强大的接口。这
以下清单概述了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
interface 显示,它扩展了InputStreamSource
接口。下面的清单显示了InputStreamSource
接口:
public interface InputStreamSource {
InputStream getInputStream() throws IOException;
}
中Resource
接口是:
-
getInputStream()
:查找并打开资源,返回InputStream
为 从资源中读取。预计每次调用都会返回一个全新的InputStream
.调用方负责关闭流。 -
exists()
:返回boolean
指示此资源是否实际存在于 物理形式。 -
isOpen()
:返回boolean
指示此资源是否表示句柄 与开放的流。如果true
这InputStream
无法多次读取,并且 必须只读取一次,然后关闭以避免资源泄漏。返回false
为 所有常用的资源实现,除了InputStreamResource
. -
getDescription()
:返回此资源的说明,用于错误 output 来执行。这通常是完全限定的文件名或 资源的实际 URL。
其他方法允许您获取实际的URL
或File
对象表示
资源(如果底层实现兼容并支持
功能)。
某些Resource
接口还实现了扩展的WritableResource
接口
对于支持写入它的资源。
Spring 本身使用Resource
abstraction 中,作为
需要资源时有许多方法签名。某些 Spring API 中的其他方法
(例如各种ApplicationContext
implementations) 采用String
它以未经修饰或简单的形式用于创建Resource
适合于
该上下文实现,或者通过String
path 中,让
caller 指定特定的Resource
必须创建和使用 implementation。
虽然Resource
interface 在 Spring 中被大量使用,而 Spring 实际上是
非常方便,可以在您自己的代码中单独用作通用工具类,以便访问
添加到资源中,即使您的代码不知道或不关心 Spring 的任何其他部分。
虽然这会将您的代码耦合到 Spring,但它实际上只将其耦合到这一小群
实用程序类,它可以作为URL
并且可以是
被认为等同于您用于此目的的任何其他库。
这Resource abstraction 不会取代 functionality。它将其包装在
可能。例如,UrlResource 包装 URL 并使用包装的URL 来执行其
工作。 |
内置Resource
实现
Spring 包含几个内置的Resource
实现:
有关Resource
实现,请参阅
“All Known Implementing Classes” 部分的Resource
javadoc 的
UrlResource
UrlResource
将java.net.URL
,并可用于访问任何对象
通常可通过 URL(例如文件、HTTPS 目标、FTP 目标)以及 URL 访问
别人。所有 URL 都有一个标准化的String
表示形式,以便适当的
标准化前缀用于指示一种 URL 类型与另一种 URL 类型。这包括file:
用于访问文件系统路径,https:
通过
HTTPS 协议 /ftp:
用于通过 FTP 访问资源等。
一个UrlResource
由 Java 代码显式使用UrlResource
构造 函数
但通常在调用采用String
参数来表示路径。对于后一种情况,JavaBeansPropertyEditor
最终决定哪种类型的Resource
以创建。如果路径字符串包含
众所周知的(即属性编辑器)前缀(例如classpath:
),它会创建一个
适当的专业Resource
对于该前缀。但是,如果它无法识别
前缀,则假定该字符串是标准 URL 字符串,并创建一个UrlResource
.
ClassPathResource
此类表示应从 Classpath 获取的资源。它使用 线程上下文类加载器、给定类加载器或 loading resources.
这Resource
implementation 支持将解析作为java.io.File
如果类路径
资源驻留在文件系统中,但不适用于驻留在
jar 中,并且尚未扩展(通过 servlet 引擎或任何环境)
添加到文件系统中。为了解决这个问题,各种Resource
implementations 始终支持
resolution 作为java.net.URL
.
一个ClassPathResource
由 Java 代码显式使用ClassPathResource
构造函数,但通常在调用采用String
参数来表示路径。对于后一种情况,JavaBeansPropertyEditor
识别特殊前缀classpath:
、字符串路径和
创建一个ClassPathResource
在那种情况下。
FileSystemResource
这是一个Resource
implementation forjava.io.File
处理。它还支持java.nio.file.Path
handles, 应用 Spring 的标准基于 String 的路径
转换,但通过java.nio.file.Files
应用程序接口。对于纯java.nio.path.Path
基于支持使用PathResource
相反。FileSystemResource
支持分辨率作为File
和URL
.
PathResource
这是一个Resource
implementation forjava.nio.file.Path
手柄, 执行所有
作和转换通过Path
应用程序接口。它支持将分辨率解析为File
和
作为URL
并且还实现了扩展的WritableResource
接口。PathResource
实际上是纯粹的java.nio.path.Path
based 替代项FileSystemResource
跟
不同createRelative
行为。
ServletContextResource
这是一个Resource
implementation forServletContext
解释
相关 Web 应用程序根目录中的相对路径。
它始终支持流访问和 URL 访问,但允许java.io.File
仅限访问
当 Web 应用程序存档扩展并且资源物理位于
文件系统。无论它是否被扩展、在文件系统上或被访问
直接从 JAR 或其他位置(如数据库)实际上是
依赖于 Servlet 容器。
InputStreamResource
一InputStreamResource
是一个Resource
implementation for a givenInputStream
.它
应仅在没有特定的Resource
implementation 是适用的。在
特别,更喜欢ByteArrayResource
或任何基于文件的Resource
implementation 的 Implementations 中。
与其他Resource
implementations,这是
已打开的资源。因此,它返回true
从isOpen()
.如果出现以下情况,请勿使用
您需要将资源描述符保留在某个位置,或者如果您需要读取流
多次。
这ResourceLoader
接口
这ResourceLoader
interface 的 API 是由可以返回
(即 load)Resource
实例。下面的清单显示了ResourceLoader
接口定义:
public interface ResourceLoader {
Resource getResource(String location);
ClassLoader getClassLoader();
}
所有应用程序上下文都实现ResourceLoader
接口。因此,所有
应用程序上下文可用于获取Resource
实例。
当您调用getResource()
在特定的应用程序上下文中,以及位置路径
specified 没有特定的前缀,则会返回一个Resource
type (即
适合该特定应用程序上下文。例如,假设以下内容
代码段针对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
.它同样会为每个上下文返回适当的对象。
因此,您可以以适合特定应用程序的方式加载资源 上下文。
另一方面,您也可以强制ClassPathResource
,无论
application context 类型,通过指定特殊的classpath:
前缀,如下所示
示例显示:
-
Java
-
Kotlin
Resource template = ctx.getResource("classpath:some/resource/path/myTemplate.txt");
val template = ctx.getResource("classpath:some/resource/path/myTemplate.txt")
同样,您可以强制UrlResource
通过指定任何标准java.net.URL
前缀。以下示例使用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
对象:
前缀 | 例 | 解释 |
---|---|---|
类路径: |
|
从 Classpath 加载。 |
文件: |
|
加载为 |
https 的 URL 中: |
|
加载为 |
(无) |
|
取决于底层 |
这ResourcePatternResolver
接口
这ResourcePatternResolver
interface 是ResourceLoader
接口
,它定义了解析位置模式(例如,Ant 样式路径
pattern) 转换为Resource
对象。
public interface ResourcePatternResolver extends ResourceLoader {
String CLASSPATH_ALL_URL_PREFIX = "classpath*:";
Resource[] getResources(String locationPattern) throws IOException;
}
从上面可以看出,这个接口还定义了一个特殊的classpath*:
资源前缀
对于类路径中的所有匹配资源。请注意,资源位置为
在本例中,预期为没有占位符的 path — 例如classpath*:/config/beans.xml
.JAR 文件或类路径中的不同目录可以
包含多个具有相同路径和名称的文件。有关更多详细信息,请参阅 Application Context Constructor Resource Paths 及其子部分中的通配符
on 通配符支持与classpath*:
resource 前缀。
传入的ResourceLoader
(例如,通过ResourceLoaderAware
semantics)可以检查
它也实现了这个扩展接口。
PathMatchingResourcePatternResolver
是可用的独立实现
在ApplicationContext
,也被ResourceArrayPropertyEditor
为
填充Resource[]
bean 属性。PathMatchingResourcePatternResolver
能够
将指定的资源位置路径解析为一个或多个匹配项Resource
对象。
源路径可以是一个简单的路径,该路径具有与目标的一对一映射Resource
,或者可能包含特殊的classpath*:
前缀和/或内部
Ant 样式的正则表达式(使用 Spring 的org.springframework.util.AntPathMatcher
实用程序)。后者两者都是有效的
通配符。
默认的 |
这ResourceLoaderAware
接口
这ResourceLoaderAware
interface 是一个特殊的回调接口,用于标识
组件,这些组件希望提供ResourceLoader
参考。以下清单
显示了ResourceLoaderAware
接口:
public interface ResourceLoaderAware {
void setResourceLoader(ResourceLoader resourceLoader);
}
当类实现ResourceLoaderAware
并部署到应用程序上下文中
(作为 Spring 管理的 bean),它被识别为ResourceLoaderAware
按应用程序
上下文。然后,应用程序上下文调用setResourceLoader(ResourceLoader)
,
将自身作为参数提供(请记住,Spring 中的所有应用程序上下文都实现了
这ResourceLoader
接口)。
由于ApplicationContext
是一个ResourceLoader
,该 bean 还可以实现ApplicationContextAware
接口,并使用提供的 Application Context 直接
load 资源。但是,一般来说,最好使用专用的ResourceLoader
界面。该代码将仅与资源加载耦合
interface(可以认为是一个 Util 接口),而不是整个 SpringApplicationContext
接口。
在应用程序组件中,您还可以依赖ResourceLoader
如
实现ResourceLoaderAware
接口。传统的
constructor
和byType
自动装配模式(如 自动装配协作者中所述)
能够提供ResourceLoader
对于构造函数参数或
setter 方法参数。为了获得更大的灵活性(包括
autowire fields 和多个参数方法),请考虑使用基于注释的
自动装配功能。在这种情况下,ResourceLoader
自动连接到字段,
constructor 参数或方法参数,该参数需要ResourceLoader
type 作为 long
由于有问题的字段、构造函数或方法带有@Autowired
注解。
有关更多信息,请参阅用@Autowired
.
加载一个或多个Resource 包含通配符的资源路径的 objects
或使用特殊的classpath*: 资源前缀,请考虑使用ResourcePatternResolver 自动连接到您的
应用程序组件,而不是ResourceLoader . |
作为依赖项的资源
如果 Bean 本身将通过某种排序来确定和提供资源路径
的 Bean 使用ResourceLoader
或ResourcePatternResolver
interface 加载资源。例如,考虑 loading
中,所需的特定资源取决于
用户的角色。如果资源是静态的,则消除对ResourceLoader
接口(或ResourcePatternResolver
接口)完全具有
bean 公开了Resource
属性,并期望它们被注入其中。
然后注入这些属性变得微不足道的是,所有应用程序上下文
注册并使用特殊的 JavaBeansPropertyEditor
,它可以将String
路径
自Resource
对象。例如,以下MyBean
类具有template
type 为Resource
.
-
Java
-
Kotlin
public class MyBean {
private Resource template;
public setTemplate(Resource template) {
this.template = template;
}
// ...
}
class MyBean(var template: Resource)
在 XML 配置文件中,template
属性可以使用简单的
string 的 String,如下例所示:
<bean id="myBean" class="example.MyBean">
<property name="template" value="some/resource/path/myTemplate.txt"/>
</bean>
请注意,资源路径没有前缀。因此,由于应用程序上下文
本身将用作ResourceLoader
,资源将通过ClassPathResource
一个FileSystemResource
或ServletContextResource
根据
应用程序上下文的确切类型。
如果您需要强制使用特定的Resource
type,可以使用前缀。这
以下两个示例展示了如何强制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
(请参阅 Environment Abstraction)。然后,可以通过@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)
如果我们想支持在多个
位置 — 例如,在 Classpath 的多个 jar 中 — 我们可以
使用特殊的classpath*:
前缀和通配符来定义templates.path
key 指定为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 文件。
当此类位置路径没有前缀时,特定的Resource
类型构建自
该路径 和 用于加载 bean 定义的路径取决于 并且适合于
特定的应用程序上下文。例如,请考虑以下示例,该示例会创建一个ClassPathXmlApplicationContext
:
-
Java
-
Kotlin
ApplicationContext ctx = new ClassPathXmlApplicationContext("conf/appContext.xml");
val ctx = ClassPathXmlApplicationContext("conf/appContext.xml")
bean 定义是从 classpath 加载的,因为ClassPathResource
是
使用。但是,请考虑以下示例,该示例会创建一个FileSystemXmlApplicationContext
:
-
Java
-
Kotlin
ApplicationContext ctx =
new FileSystemXmlApplicationContext("conf/appContext.xml");
val ctx = FileSystemXmlApplicationContext("conf/appContext.xml")
现在,bean 定义是从文件系统位置加载的(在本例中,相对于 当前工作目录)。
请注意,使用特殊的classpath
前缀或标准 URL 前缀
location path 会覆盖默认类型Resource
created 以加载 bean
定义。请考虑以下示例:
-
Java
-
Kotlin
ApplicationContext ctx =
new FileSystemXmlApplicationContext("classpath:conf/appContext.xml");
val ctx = FileSystemXmlApplicationContext("classpath:conf/appContext.xml")
用FileSystemXmlApplicationContext
从 Classpath 中加载 bean 定义。
但是,它仍然是一个FileSystemXmlApplicationContext
.如果它随后被用作ResourceLoader
,则任何无前缀的路径仍被视为文件系统路径。
构建ClassPathXmlApplicationContext
实例 — 快捷方式
这ClassPathXmlApplicationContext
公开了许多构造函数以启用
方便的实例化。基本思想是,您可以只提供一个字符串数组
,仅包含 XML 文件本身的文件名(没有前导路径
信息),并提供Class
.这ClassPathXmlApplicationContext
然后派生
来自提供的类的路径信息。
请考虑以下目录布局:
com/ example/ services.xml repositories.xml MessengerService.class
以下示例显示了ClassPathXmlApplicationContext
实例由
在名为services.xml
和repositories.xml
(位于
classpath) 可以实例化:
-
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 了解有关各种构造函数的详细信息。
应用程序上下文构造函数资源路径中的通配符
应用程序上下文构造函数值中的资源路径可以是简单路径(如
前面所示),每个 API 都有一个到目标的一对一映射Resource
或
或者,可能包含特殊的classpath*:
前缀或内部 Ant 样式模式
(使用 Spring 的PathMatcher
实用程序)。后者两者都是有效的
通配符。
此机制的一个用途是当您需要执行组件样式的应用程序组装时。都
组件可以将上下文定义片段发布到已知的位置路径,并且
当使用前缀为classpath*:
,则会自动选取所有组件片段。
请注意,此通配符特定于应用程序上下文中资源路径的使用
构造函数(或者当您使用PathMatcher
Utility 类层次结构),并且是
在构建时解决。它与Resource
键入自身。
您不能使用classpath*:
前缀来构造实际的Resource
如
一个资源一次只指向一个资源。
Ant-style 模式
路径位置可以包含 Ant 样式模式,如下例所示:
/WEB-INF/*-context.xml com/mycompany/**/applicationContext.xml file:C:/some/path/*-context.xml classpath:com/mycompany/**/applicationContext.xml
当路径位置包含 Ant 样式模式时,解析程序遵循更复杂的
过程以尝试解析通配符。它生成一个Resource
对于到
last 非通配符段并从中获取 URL。如果此 URL 不是jar:
URL 或
特定于容器的变体(例如zip:
在 WebLogic 中,wsjar
在 WebSphere 中,依此类推),
一个java.io.File
从中获取,并用于通过遍历
文件系统。对于 jar URL,解析器要么获得java.net.JarURLConnection
或手动解析 jar URL,然后遍历
内容解析通配符。
对可移植性的影响
如果指定的路径已经是file
URL(要么隐式,因为 baseResourceLoader
是文件系统 One 或显式的),则通配符保证为
以完全便携的方式工作。
如果指定的路径是classpath
location,则解析程序必须获取最后一个
非通配符路径段 URL,方法是将Classloader.getResource()
叫。由于这个
只是路径的一个节点(不是末尾的文件),它实际上是 undefined 的(在ClassLoader
javadoc) 中返回的 URL 类型。在实践中,
它始终是一个java.io.File
表示目录(其中 Classpath 资源
解析为文件系统位置)或某种类型的 jar URL(其中 Classpath 资源
解析为 jar 位置)。尽管如此,此作仍然存在可移植性问题。
如果获取了最后一个非通配符段的 jar URL,则解析程序必须能够
获取java.net.JarURLConnection
或手动解析 jar URL,以便能够
遍历 jar 的内容并解析通配符。这在大多数环境中都有效
但在其他 API 中失败,我们强烈建议 resources 的通配符解析
来自 jars 在您依赖它之前,请在您的特定环境中对其进行全面测试。
这classpath*:
前缀
在构建基于 XML 的应用程序上下文时,位置字符串可以使用
特殊classpath*:
前缀,如下例所示:
-
Java
-
Kotlin
ApplicationContext ctx =
new ClassPathXmlApplicationContext("classpath*:conf/appContext.xml");
val ctx = ClassPathXmlApplicationContext("classpath*:conf/appContext.xml")
此特殊前缀指定与给定名称匹配的所有 Classpath 资源
必须获取(在内部,这基本上是通过调用ClassLoader.getResources(…)
),然后合并形成最终应用程序
context 定义。
通配符类路径依赖于getResources() 底层ClassLoader .由于现在大多数应用程序服务器都提供自己的ClassLoader 实现时,行为可能会有所不同,尤其是在处理 jar 文件时。一个
简单测试以检查classpath* works 是使用ClassLoader 加载文件
在 Classpath 上的 jar 中:getClass().getClassLoader().getResources("<someFileInsideTheJar>") .尝试此测试
具有相同名称但位于两个不同位置的文件 — 例如,文件
具有相同的名称和相同的路径,但在 Classpath 上的不同 jar 中。如果
返回不适当的结果,请查看 Application Server 文档了解设置
这可能会影响ClassLoader 行为。 |
您还可以将classpath*:
前缀替换为PathMatcher
pattern 中
位置路径的其余部分(例如classpath*:META-INF/*-beans.xml
).在这个
的情况下,解决策略相当简单:AClassLoader.getResources()
call 为
用于获取
类加载器层次结构,然后从每个资源中,相同的PathMatcher
分辨率
前面描述的策略用于通配符子路径。
与通配符相关的其他说明
请注意,classpath*:
,当与 Ant 样式模式结合使用时,仅有效
可靠地使用至少一个根目录,除非实际的
目标文件驻留在文件系统中。这意味着classpath*:*.xml
可能不会从 jar 文件的根目录中检索文件,而只能检索
从扩展目录的根目录。
Spring 检索 Classpath 条目的能力源自 JDK 的ClassLoader.getResources()
方法,该方法仅返回
空字符串(指示要搜索的潜在根)。Spring 计算URLClassLoader
运行时配置和java.class.path
在 jar 文件中的清单
,但不能保证这会导致可移植行为。
扫描 classpath 包需要存在相应的目录
条目。使用 Ant 构建 JAR 时,请勿激活 在模块路径(Java Module System)上,Spring 的类路径扫描通常工作为 预期。在这里,强烈建议将资源放入专用目录, 避免了上述搜索 jar 文件根级别的可移植性问题。 |
Ant 样式的模式,其中classpath:
不保证 resources 能找到匹配项
resources(如果要搜索的根包在多个 Classpath 位置中可用)。
请考虑以下资源位置示例:
com/mycompany/package1/service-context.xml
现在考虑一个 Ant 样式的路径,有人可能会使用它来尝试查找该文件:
classpath:com/mycompany/**/service-context.xml
这样的资源可能只存在于 Classpath 中的一个位置,但是当
前面的示例用于尝试解决它,解析器在(第一个)
返回的 URLgetResource("com/mycompany");
.如果此基础包节点存在于
倍数ClassLoader
locations 中,所需的资源可能不存在于第一个
找到位置。因此,在这种情况下,您应该更喜欢使用classpath*:
使用
相同的 Ant 样式模式,它搜索包含com.mycompany
基础包:classpath*:com/mycompany/**/service-context.xml
.
FileSystemResource
警告
一个FileSystemResource
未附加到FileSystemApplicationContext
(那个
是,当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")
以下示例也是等效的(即使它们不同是有意义的,但作为一个 case 是相对的,另一个是绝对的):
-
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
和
强制使用UrlResource
通过使用file:
URL 前缀。以下示例
演示如何执行此作:
-
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")