- 浏览: 94698 次
- 性别:
- 来自: 杭州
文章分类
- 全部博客 (68)
- Spring (3)
- Java (9)
- Linux (5)
- 设计模式 (2)
- Web (2)
- Mac (6)
- Ubuntu (4)
- Windows (1)
- DB (2)
- plsql (0)
- Cache (2)
- Android (1)
- Javascript (1)
- 数据结构及算法 (1)
- 性能调优 (1)
- 并发及多线程 (2)
- Hadoop (1)
- 数据挖掘 (1)
- 版本控制 (1)
- Log4j (1)
- Node.js (1)
- NoSQL (1)
- 框架 (2)
- maven (2)
- 搜索及大数据处理 (1)
- Object-C (10)
- IOS (5)
- Lua (0)
- Ruby (1)
- Python (0)
- TCP/IP网络编程 (1)
- Objective-C (1)
- 前端 (1)
最新评论
Java标准的 java.net.URL接口和多种URL前缀处理类并不能很好地满足所有底层资源访问的需要。比如,还没有能从类路径或者ServletContext 的相对路径获得资源的标准URL实现。虽然能为特定的URL前缀注册新的处理类(类似已有前缀 http: 的处理类),但是这样做通常比较复杂,而且URL接口还缺少一些有用的功能,比如检查指向的资源是否存在的方法。
4.2. 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。每次调用预期会返回一个新的 InputStream,由调用者负责关闭这个流。
exists(): 返回标识这个资源在物理上是否的确存在的 boolean 值。
isOpen(): 返回标识这个资源是否有已打开流的处理类的 boolean 值。如果为 true,则此InputStream 就不能被多次读取,而且只能被读取一次然后关闭以避免资源泄漏。除了 InputStreamResource,常见的resource实现都会返回 false。
getDescription(): 返回资源的描述,一般在与此资源相关的错误输出时使用。此描述通常是完整的文件名或实际的URL地址。
其它方法让你获得表示该资源的实际的 URL 或 File 对象(如果隐含的实现支持该方法并保持一致的话)。
Spring自身处理资源请求的多种方法声明中将Resource 抽象作为参数而广泛地使用。 Spring APIs中的一些其它方法(比如许多ApplicationContext的实现构造函数),使用普通格式的 String 来创建与context相符的Resource,也可以使用特殊的路径String前缀来让调用者指定创建和使用特定的 Resource 实现。
Resource不仅被Spring自身大量地使用,它也非常适合在你自己的代码中独立作为辅助类使用。用户代码甚至可以在不用关心Spring其它部分的情况下访问资源。这样的确会造成代码与Spring之间的耦合,但也仅仅是与很少量的辅助类耦合。这些类可以作为比 URL 更有效的替代,而且与为这个目的而使用其它类库基本相似。
需要注意的是 Resource 抽象并没有改变功能:它尽量使用封装。 比如 UrlResource 封装了URL,然后使用被封装的 URL 来工作。
4.3. 内置 Resource 实现
Spring提供了很多 Resource 的实现:
4.3.1. UrlResource
UrlResource 封装了java.net.URL,它能够被用来访问任何通过URL可以获得的对象,例如:文件、HTTP对象、FTP对象等。所有的URL都有个标准的 String表示,这些标准前缀可以标识不同的URL类型,包括file:访问文件系统路径,http: 通过HTTP协议访问的资源,ftp: 通过FTP访问的资源等等。
UrlResource 对象可以在Java代码中显式地使用 UrlResource 构造函数来创建。但更多的是通过调用带表示路径的 String 参数的API函数隐式地创建。在后一种情况下,JavaBeans的 PropertyEditor 会最终决定哪种类型的 Resource 被创建。如果这个字符串包含一些众所周知的前缀,比如 classpath:,它就会创建一个对应的已串行化的 Resource。 然而,如果不能分辨出这个前缀,就会假定它是个标准的URL字符串,然后创建UrlResource。
4.3.2. ClassPathResource
这个类标识从classpath获得的资源。它会使用线程context的类加载器(class loader)、给定的类加载器或者用来载入资源的给定类。
如果类路径上的资源存在于文件系统里,这个 Resource 的实现会提供类似于java.io.File的功能。而如果资源是存在于还未解开(被servlet引擎或其它的环境解开)的jar包中,一般提供类似于java.net.URL 的功能。
ClassPathResource对象可以在Java代码中显式地使用ClassPathResource 构造函数来创建。但更多的是通过调用带表示路径的String参数的API函数隐式地创建。在后一种情况下,JavaBeans的 PropertyEditor 会分辨字符串中 classpath: 前缀,然后相应创建 ClassPathResource。
4.3.3. FileSystemResource
这是为处理 java.io.File 而准备的Resource实现。它既可以作为File提供,也可以作为URL。
4.3.4. ServletContextResource
这是为 ServletContext 资源提供的 Resource 实现,它负责解析相关web应用根目录中的相对路径。
它始终支持以流和URL的方式访问。 但是只有当web应用包被解开并且资源在文件系统的物理路径上时,才允许以 java.io.File 方式访问。是否解开并且在文件系统中访问,还是直接从JAR包访问或以其它方式访问如DB(这是可以想象的),仅取决于Servlet容器。
4.3.5. InputStreamResource
这是为给定的 InputStream 而准备的 Resource 实现。它只有在没有其它合适的 Resource 实现时才使用。而且,只要有可能就尽量使用 ByteArrayResource 或者其它基于文件的Resource 实现。
与其它 Resource 实现不同的是,这是个 已经 打开资源的描述符-因此 isOpen() 函数返回 true。 如果你需要在其它位置保持这个资源的描述符或者多次读取一个流,请不要使用它。
4.3.6. ByteArrayResource
这是为给定的byte数组准备的 Resource 实现。 它会为给定的byte数组构造一个 ByteArrayInputStream。
它在从任何给定的byte数组读取内容时很有用,因为不用转换成单一作用的 InputStreamResource。
4.4. The ResourceLoader
ResourceLoader 接口由能返回(或者载入)Resource 实例的对象来实现。
public interface ResourceLoader {
Resource getResource(String location);
}
所有的application context都实现了 ResourceLoader 接口, 因此它们可以用来获取Resource 实例。
当你调用特定application context的 getResource() 方法, 而且资源路径并没有特定的前缀时,你将获得与该application context相应的 Resource 类型。例如:假定下面的代码片断是基于ClassPathXmlApplicationContext 实例上执行的:
Resource template = ctx.getResource("some/resource/path/myTemplate.txt");
这将返回ClassPathResource;如果是基于FileSystemXmlApplicationContext 实例上执行的,那你将获得FileSystemResource。而对于 WebApplicationContext 你将获得ServletContextResource,依此类推。
这样你可以在特定的application context中用流行的方法载入资源。
另一方面,无论什么类型的application context, 你可以通过使用特定的前缀 classpath: 强制使用ClassPathResource。
Resource template = ctx.getResource("classpath:some/resource/path/myTemplate.txt");
同样的,你可以用任何标准的 java.net.URL 前缀,强制使用 UrlResource :
Resource template = ctx.getResource("file:/some/resource/path/myTemplate.txt");
Resource template = ctx.getResource("http://myhost.com/resource/path/myTemplate.txt");
下面的表格概述了 String 到 Resource 的转换规则:
Table 4.1. Resource strings
Prefix Example Explanation
classpath:
classpath:com/myapp/config.xml
Loaded from the classpath.
file:
file:/data/config.xml
Loaded as a URL, from the filesystem. [a]
http:
http://myserver/logo.png
Loaded as a URL.
(none)
/data/config.xml
Depends on the underlying ApplicationContext.
[a] But see also the section entitled Section 4.7.3, “ FileSystemResource 提示”.
4.5. ResourceLoaderAware 接口
ResourceLoaderAware是特殊的标记接口,它希望拥有一个ResourceLoader 引用的对象。
public interface ResourceLoaderAware {
void setResourceLoader(ResourceLoader resourceLoader);
}
当实现了 ResourceLoaderAware接口的类部署到application context(比如受Spring管理的bean)中时,它会被application context识别为 ResourceLoaderAware。接着application context会调用setResourceLoader(ResourceLoader)方法,并把自身作为参数传入该方法(记住,所有Spring里的application context都实现了ResourceLoader接口)。
既然 ApplicationContext 就是ResourceLoader,那么该bean就可以实现 ApplicationContextAware接口并直接使用所提供的application context来载入资源,但是通常更适合使用特定的满足所有需要的 ResourceLoader实现。 这样一来,代码只需要依赖于可以看作辅助接口的资源载入接口,而不用依赖于整个Spring ApplicationContext 接口。
4.6. 把Resources 作为属性来配置
如果bean自身希望通过一些动态方式决定和提供资源路径,那么让这个bean通过 ResourceLoader 接口去载入资源就很有意义了。考虑一个载入某类模板的例子,其中需要哪种特殊类型由用户的角色决定。 如果同时资源是静态的,完全不使用 ResourceLoader 接口很有意义, 这样只需让这些bean暴露所需的 Resource 属性,并保证他们会被注入。
让注入这些属性变得比较繁琐的原因是,所有的application context注册并使用了能把 String 路径变为 Resource 对象的特殊 PropertyEditor JavaBeans。因此如果 myBean 有 Resource 类型的模板属性, 那它就能够使用简单的字符串配置该资源,如下所示:
bean id="myBean" class="...">
<property name="template" value="some/resource/path/myTemplate.txt" />
</bean>
可以看到资源路径没有前缀,因为application context本身要被作为 ResourceLoader 使用,这个资源会被载入为ClassPathResource、 FileSystemResource、 ServletContextResource等等,这取决于context类型。
如果有必要强制使用特殊的 Resource 类型,那你就可以使用前缀。下面的两个例子说明了如何强制使用 ClassPathResource 和 UrlResource (其中的第二个被用来访问文件系统中的文件)。
<property name="template" value="classpath:some/resource/path/myTemplate.txt"/>
<property name="template" value="file:/some/resource/path/myTemplate.txt"/>
4.7. Application contexts 和Resource 路径
4.7.1. 构造application contexts
application context构造器通常使用字符串或字符串数组作为资源(比如组成context定义 的XML文件)的定位路径。
当这样的定位路径没有前缀时,指定的 Resource 类型会通过这个路径来被创建并被用来载入bean的定义,这都取决于你所指定的application context。 例如,如果你使用下面的代码来创建ClassPathXmlApplicationContext :
ApplicationContext ctx = new ClassPathXmlApplicationContext("conf/appContext.xml");
这些Bean的定义会通过classpath载入并使用ClassPathResource。 而如果你象下面这么创建FileSystemXmlApplicationContext:gramlisting>ApplicationContext ctx = new FileSystemClassPathXmlApplicationContext("conf/appContext.xml");
这些Bean的定义会通过文件系统从相对于当前工作目录中被载入。
请注意如果定位路径使用classpath前缀或标准的URL前缀,那它就会覆盖默认的Resource 类型。因此下面的FileSystemXmlApplicationContext...
ApplicationContext ctx =
new FileSystemXmlApplicationContext("classpath:conf/appContext.xml");
...实际上会通过classpath载入其bean定义。然而它仍是个FileSystemXmlApplicationContext。如果后面它被当作ResourceLoader 来使用,那么任何没有使用前缀的路径依然会被当作一个文件系统路径。
4.7.1.1. 创建 ClassPathXmlApplicationContext 实例 - 简介
ClassPathXmlApplicationContext 提供了多种构造方法以便于初始化。但其核心是,如果我们仅仅提供由XML文件名组成的字符串数组(没有完整路径信息), 而且还提供了Class;那么该ClassPathXmlApplicationContext就会从给定的类中抽取路径信息。
希望通过一个示例把这些阐述清楚。假设有这样的目录结构:
com/
foo/
services.xml
daos.xml
MessengerService.class
由 'services.xml' 和 'daos.xml' 中定义的bean组成的 ClassPathXmlApplicationContext 实例会象这样地来实例化...
ApplicationContext ctx = new ClassPathXmlApplicationContext(
new String[] {"services.xml", "daos.xml"}, MessengerService.class);
4.7.2. classpath*: 前缀
当构造基于XML的application context时,路径字符串可能使用特殊的 classpath*: 前缀:
ApplicationContext ctx =
new ClassPathXmlApplicationContext("classpath*:conf/appContext.xml");
此前缀表示所有与给定名称匹配的classpath资源都应该被获取(其中,这经常会在调用 ClassLoader.getResources(...)) 时发生),并接着将那些资源全并成最终的application context定义。
该机制的一个用处就是做组件类型的应用组装。所有的组件都可以用通用的定位路径“发布”context定义片断, 这样当使用相同的 classpath* 前缀创建最终的application context时,所有的组件片断都会被自动装入。
请注意这个特殊的前缀是application context专用,它在构造时使用。这与 Resource 类型本身没有关联。因为同一时刻只能指向一个资源,所以不能使用 classpath* 前缀来构造实际的Resource。
4.7.3. FileSystemResource 提示
一个并没有与 FileSystemApplicationContext 绑定的 FileSystemResource(也就是说FileSystemApplicationContext 并不是真正的ResourceLoader),会象你期望的那样分辨绝对和相对路径。 相对路径是相对于当前的工作目录,而绝对路径是相对与文件系统的根目录。
为了向前兼容的目的,当 FileSystemApplicationContext 是个 ResourceLoader 时它会发生变化。FileSystemApplicationContext 会简单地让所有绑定的 FileSystemResource 实例把绝对路径都当成相对路径, 而不管它们是否以反斜杠开头。也就是说,下面的含义是相同的:
ApplicationContext ctx =
new FileSystemClassPathXmlApplicationContext("conf/context.xml");
ApplicationContext ctx =
new FileSystemClassPathXmlApplicationContext("/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 it's definition via a UrlResource
ApplicationContext ctx =
new FileSystemXmlApplicationContext("file:/conf/context.xml");
4.2. 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。每次调用预期会返回一个新的 InputStream,由调用者负责关闭这个流。
exists(): 返回标识这个资源在物理上是否的确存在的 boolean 值。
isOpen(): 返回标识这个资源是否有已打开流的处理类的 boolean 值。如果为 true,则此InputStream 就不能被多次读取,而且只能被读取一次然后关闭以避免资源泄漏。除了 InputStreamResource,常见的resource实现都会返回 false。
getDescription(): 返回资源的描述,一般在与此资源相关的错误输出时使用。此描述通常是完整的文件名或实际的URL地址。
其它方法让你获得表示该资源的实际的 URL 或 File 对象(如果隐含的实现支持该方法并保持一致的话)。
Spring自身处理资源请求的多种方法声明中将Resource 抽象作为参数而广泛地使用。 Spring APIs中的一些其它方法(比如许多ApplicationContext的实现构造函数),使用普通格式的 String 来创建与context相符的Resource,也可以使用特殊的路径String前缀来让调用者指定创建和使用特定的 Resource 实现。
Resource不仅被Spring自身大量地使用,它也非常适合在你自己的代码中独立作为辅助类使用。用户代码甚至可以在不用关心Spring其它部分的情况下访问资源。这样的确会造成代码与Spring之间的耦合,但也仅仅是与很少量的辅助类耦合。这些类可以作为比 URL 更有效的替代,而且与为这个目的而使用其它类库基本相似。
需要注意的是 Resource 抽象并没有改变功能:它尽量使用封装。 比如 UrlResource 封装了URL,然后使用被封装的 URL 来工作。
4.3. 内置 Resource 实现
Spring提供了很多 Resource 的实现:
4.3.1. UrlResource
UrlResource 封装了java.net.URL,它能够被用来访问任何通过URL可以获得的对象,例如:文件、HTTP对象、FTP对象等。所有的URL都有个标准的 String表示,这些标准前缀可以标识不同的URL类型,包括file:访问文件系统路径,http: 通过HTTP协议访问的资源,ftp: 通过FTP访问的资源等等。
UrlResource 对象可以在Java代码中显式地使用 UrlResource 构造函数来创建。但更多的是通过调用带表示路径的 String 参数的API函数隐式地创建。在后一种情况下,JavaBeans的 PropertyEditor 会最终决定哪种类型的 Resource 被创建。如果这个字符串包含一些众所周知的前缀,比如 classpath:,它就会创建一个对应的已串行化的 Resource。 然而,如果不能分辨出这个前缀,就会假定它是个标准的URL字符串,然后创建UrlResource。
4.3.2. ClassPathResource
这个类标识从classpath获得的资源。它会使用线程context的类加载器(class loader)、给定的类加载器或者用来载入资源的给定类。
如果类路径上的资源存在于文件系统里,这个 Resource 的实现会提供类似于java.io.File的功能。而如果资源是存在于还未解开(被servlet引擎或其它的环境解开)的jar包中,一般提供类似于java.net.URL 的功能。
ClassPathResource对象可以在Java代码中显式地使用ClassPathResource 构造函数来创建。但更多的是通过调用带表示路径的String参数的API函数隐式地创建。在后一种情况下,JavaBeans的 PropertyEditor 会分辨字符串中 classpath: 前缀,然后相应创建 ClassPathResource。
4.3.3. FileSystemResource
这是为处理 java.io.File 而准备的Resource实现。它既可以作为File提供,也可以作为URL。
4.3.4. ServletContextResource
这是为 ServletContext 资源提供的 Resource 实现,它负责解析相关web应用根目录中的相对路径。
它始终支持以流和URL的方式访问。 但是只有当web应用包被解开并且资源在文件系统的物理路径上时,才允许以 java.io.File 方式访问。是否解开并且在文件系统中访问,还是直接从JAR包访问或以其它方式访问如DB(这是可以想象的),仅取决于Servlet容器。
4.3.5. InputStreamResource
这是为给定的 InputStream 而准备的 Resource 实现。它只有在没有其它合适的 Resource 实现时才使用。而且,只要有可能就尽量使用 ByteArrayResource 或者其它基于文件的Resource 实现。
与其它 Resource 实现不同的是,这是个 已经 打开资源的描述符-因此 isOpen() 函数返回 true。 如果你需要在其它位置保持这个资源的描述符或者多次读取一个流,请不要使用它。
4.3.6. ByteArrayResource
这是为给定的byte数组准备的 Resource 实现。 它会为给定的byte数组构造一个 ByteArrayInputStream。
它在从任何给定的byte数组读取内容时很有用,因为不用转换成单一作用的 InputStreamResource。
4.4. The ResourceLoader
ResourceLoader 接口由能返回(或者载入)Resource 实例的对象来实现。
public interface ResourceLoader {
Resource getResource(String location);
}
所有的application context都实现了 ResourceLoader 接口, 因此它们可以用来获取Resource 实例。
当你调用特定application context的 getResource() 方法, 而且资源路径并没有特定的前缀时,你将获得与该application context相应的 Resource 类型。例如:假定下面的代码片断是基于ClassPathXmlApplicationContext 实例上执行的:
Resource template = ctx.getResource("some/resource/path/myTemplate.txt");
这将返回ClassPathResource;如果是基于FileSystemXmlApplicationContext 实例上执行的,那你将获得FileSystemResource。而对于 WebApplicationContext 你将获得ServletContextResource,依此类推。
这样你可以在特定的application context中用流行的方法载入资源。
另一方面,无论什么类型的application context, 你可以通过使用特定的前缀 classpath: 强制使用ClassPathResource。
Resource template = ctx.getResource("classpath:some/resource/path/myTemplate.txt");
同样的,你可以用任何标准的 java.net.URL 前缀,强制使用 UrlResource :
Resource template = ctx.getResource("file:/some/resource/path/myTemplate.txt");
Resource template = ctx.getResource("http://myhost.com/resource/path/myTemplate.txt");
下面的表格概述了 String 到 Resource 的转换规则:
Table 4.1. Resource strings
Prefix Example Explanation
classpath:
classpath:com/myapp/config.xml
Loaded from the classpath.
file:
file:/data/config.xml
Loaded as a URL, from the filesystem. [a]
http:
http://myserver/logo.png
Loaded as a URL.
(none)
/data/config.xml
Depends on the underlying ApplicationContext.
[a] But see also the section entitled Section 4.7.3, “ FileSystemResource 提示”.
4.5. ResourceLoaderAware 接口
ResourceLoaderAware是特殊的标记接口,它希望拥有一个ResourceLoader 引用的对象。
public interface ResourceLoaderAware {
void setResourceLoader(ResourceLoader resourceLoader);
}
当实现了 ResourceLoaderAware接口的类部署到application context(比如受Spring管理的bean)中时,它会被application context识别为 ResourceLoaderAware。接着application context会调用setResourceLoader(ResourceLoader)方法,并把自身作为参数传入该方法(记住,所有Spring里的application context都实现了ResourceLoader接口)。
既然 ApplicationContext 就是ResourceLoader,那么该bean就可以实现 ApplicationContextAware接口并直接使用所提供的application context来载入资源,但是通常更适合使用特定的满足所有需要的 ResourceLoader实现。 这样一来,代码只需要依赖于可以看作辅助接口的资源载入接口,而不用依赖于整个Spring ApplicationContext 接口。
4.6. 把Resources 作为属性来配置
如果bean自身希望通过一些动态方式决定和提供资源路径,那么让这个bean通过 ResourceLoader 接口去载入资源就很有意义了。考虑一个载入某类模板的例子,其中需要哪种特殊类型由用户的角色决定。 如果同时资源是静态的,完全不使用 ResourceLoader 接口很有意义, 这样只需让这些bean暴露所需的 Resource 属性,并保证他们会被注入。
让注入这些属性变得比较繁琐的原因是,所有的application context注册并使用了能把 String 路径变为 Resource 对象的特殊 PropertyEditor JavaBeans。因此如果 myBean 有 Resource 类型的模板属性, 那它就能够使用简单的字符串配置该资源,如下所示:
bean id="myBean" class="...">
<property name="template" value="some/resource/path/myTemplate.txt" />
</bean>
可以看到资源路径没有前缀,因为application context本身要被作为 ResourceLoader 使用,这个资源会被载入为ClassPathResource、 FileSystemResource、 ServletContextResource等等,这取决于context类型。
如果有必要强制使用特殊的 Resource 类型,那你就可以使用前缀。下面的两个例子说明了如何强制使用 ClassPathResource 和 UrlResource (其中的第二个被用来访问文件系统中的文件)。
<property name="template" value="classpath:some/resource/path/myTemplate.txt"/>
<property name="template" value="file:/some/resource/path/myTemplate.txt"/>
4.7. Application contexts 和Resource 路径
4.7.1. 构造application contexts
application context构造器通常使用字符串或字符串数组作为资源(比如组成context定义 的XML文件)的定位路径。
当这样的定位路径没有前缀时,指定的 Resource 类型会通过这个路径来被创建并被用来载入bean的定义,这都取决于你所指定的application context。 例如,如果你使用下面的代码来创建ClassPathXmlApplicationContext :
ApplicationContext ctx = new ClassPathXmlApplicationContext("conf/appContext.xml");
这些Bean的定义会通过classpath载入并使用ClassPathResource。 而如果你象下面这么创建FileSystemXmlApplicationContext:gramlisting>ApplicationContext ctx = new FileSystemClassPathXmlApplicationContext("conf/appContext.xml");
这些Bean的定义会通过文件系统从相对于当前工作目录中被载入。
请注意如果定位路径使用classpath前缀或标准的URL前缀,那它就会覆盖默认的Resource 类型。因此下面的FileSystemXmlApplicationContext...
ApplicationContext ctx =
new FileSystemXmlApplicationContext("classpath:conf/appContext.xml");
...实际上会通过classpath载入其bean定义。然而它仍是个FileSystemXmlApplicationContext。如果后面它被当作ResourceLoader 来使用,那么任何没有使用前缀的路径依然会被当作一个文件系统路径。
4.7.1.1. 创建 ClassPathXmlApplicationContext 实例 - 简介
ClassPathXmlApplicationContext 提供了多种构造方法以便于初始化。但其核心是,如果我们仅仅提供由XML文件名组成的字符串数组(没有完整路径信息), 而且还提供了Class;那么该ClassPathXmlApplicationContext就会从给定的类中抽取路径信息。
希望通过一个示例把这些阐述清楚。假设有这样的目录结构:
com/
foo/
services.xml
daos.xml
MessengerService.class
由 'services.xml' 和 'daos.xml' 中定义的bean组成的 ClassPathXmlApplicationContext 实例会象这样地来实例化...
ApplicationContext ctx = new ClassPathXmlApplicationContext(
new String[] {"services.xml", "daos.xml"}, MessengerService.class);
4.7.2. classpath*: 前缀
当构造基于XML的application context时,路径字符串可能使用特殊的 classpath*: 前缀:
ApplicationContext ctx =
new ClassPathXmlApplicationContext("classpath*:conf/appContext.xml");
此前缀表示所有与给定名称匹配的classpath资源都应该被获取(其中,这经常会在调用 ClassLoader.getResources(...)) 时发生),并接着将那些资源全并成最终的application context定义。
该机制的一个用处就是做组件类型的应用组装。所有的组件都可以用通用的定位路径“发布”context定义片断, 这样当使用相同的 classpath* 前缀创建最终的application context时,所有的组件片断都会被自动装入。
请注意这个特殊的前缀是application context专用,它在构造时使用。这与 Resource 类型本身没有关联。因为同一时刻只能指向一个资源,所以不能使用 classpath* 前缀来构造实际的Resource。
4.7.3. FileSystemResource 提示
一个并没有与 FileSystemApplicationContext 绑定的 FileSystemResource(也就是说FileSystemApplicationContext 并不是真正的ResourceLoader),会象你期望的那样分辨绝对和相对路径。 相对路径是相对于当前的工作目录,而绝对路径是相对与文件系统的根目录。
为了向前兼容的目的,当 FileSystemApplicationContext 是个 ResourceLoader 时它会发生变化。FileSystemApplicationContext 会简单地让所有绑定的 FileSystemResource 实例把绝对路径都当成相对路径, 而不管它们是否以反斜杠开头。也就是说,下面的含义是相同的:
ApplicationContext ctx =
new FileSystemClassPathXmlApplicationContext("conf/context.xml");
ApplicationContext ctx =
new FileSystemClassPathXmlApplicationContext("/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 it's definition via a UrlResource
ApplicationContext ctx =
new FileSystemXmlApplicationContext("file:/conf/context.xml");
相关推荐
Resource Tuner是一款强大的Windows应用程序资源编辑器,它允许用户查看、修改、添加和删除各种类型的资源,如图标、位图、对话框、菜单、字符串表等,这对于软件开发人员和系统管理员来说是极其有用的工具。...
赠送jar包:osgi-resource-locator-1.0.1.jar; 赠送原API文档:osgi-resource-locator-1.0.1-javadoc.jar; 赠送源代码:osgi-resource-locator-1.0.1-sources.jar; 赠送Maven依赖信息文件:osgi-resource-locator...
《Resource Hacker:深入解析软件资源修改的艺术》 Resource Hacker,这款强大的工具,是软件开发者、本地化人员以及对软件有个性化需求的用户们的得力助手。它专为修改软件资源而设计,无论是汉化程序,还是替换...
在本文中,我们将深入探讨Resource Hacker的功能、使用方法以及它在IT行业中的应用。 Resource Hacker v5.1.6是一款绿色版软件,这意味着它无需安装,直接解压后即可运行,减少了系统负担,方便用户快速使用。绿色...
赠送jar包:osgi-resource-locator-1.0.1.jar; 赠送原API文档:osgi-resource-locator-1.0.1-javadoc.jar; 赠送源代码:osgi-resource-locator-1.0.1-sources.jar; 赠送Maven依赖信息文件:osgi-resource-locator...
在这个特定的上下文中,我们关注的是“resources_resource编号排序_”标题所指的“资源文件RESOURCE.H”,它是MFC应用中的一个重要组件。 资源文件(通常命名为RC文件)是包含应用程序界面元素定义的地方,如菜单、...
Resource Binder v3.1是一款强大的EXE资源优化与重建工具,专为IT专业人士设计,用于处理PE(Portable Executable)文件格式的资源管理。这款工具的主要功能是帮助用户对程序的资源部分进行编辑、更新和优化,从而...
"Resource Hacker文件修改(中文版)" 是一个针对Windows应用程序资源进行编辑和修改的强大工具,尤其适合程序员、软件本地化人员以及对软件界面有定制需求的用户。Resource Hacker提供了直观的图形用户界面,允许用户...
QNX 系统下 Resource Manager 最简单的例子 本文将对 QNX 系统下 Resource Manager 的最简单例子进行详细解释,介绍如何使用 Resource Manager API 实现一个简单的资源管理器。 Resource Manager 是 QNX 操作系统...
在Spring框架中,`@Resource`和`@Component`是两个重要的注解,它们用于不同的目的,但都与依赖注入(Dependency Injection,简称DI)息息相关。理解这两个注解的使用和区别是掌握Spring框架核心概念的关键。 首先...
这个工具主要用于修复VC++项目中的资源问题,并能对`resource.h`文件中的资源ID进行排序和整合。 `resource.h`文件是存储资源定义的地方,它包含了每个资源的唯一标识符(ID)。当项目发展过程中,资源ID可能因为...
《ResScope 1.96与Resource Hacker 3.6:深入解析Windows资源管理》 在Windows操作系统中,可执行文件(如.exe和.dll)包含了各种资源,如图标(ICO)、对话框(DLG)、菜单(MENU)、字符串(STRING)等。为了能够...
《LWM2M中的Object与Resource定义:深入理解物联网平台对接》 在物联网(IoT)领域, Lightweight Machine to Machine (LWM2M) 协议作为一种轻量级的通信协议,广泛应用于设备管理和服务提供。它允许远程访问和管理...
"Resource Hacker 3.4.0.79 绿色汉化版"是一款强大的资源编辑工具,主要用于修改软件中的各种资源,如对话框、图标、菜单、字符串等。这款绿色汉化版本意味着它无需安装,下载后即可直接运行,并且已经过汉化处理,...
ResourceHacker是一款强大的资源编辑器,特别适用于处理Windows应用程序中的各种资源。x32表示这是32位版本,适用于32位操作系统。v4.5.28是该软件的具体版本号,通常每个版本都会有性能优化和新功能的添加。便携版...
本文将深入探讨如何通过注解(Annotation)和`@Resource`来实现自动装配,以及其背后的源码实现。 ### 一、注解驱动的自动装配 在Spring 2.5引入了注解支持后,开发者可以使用注解来声明Bean的属性、方法或构造...
这通常涉及到使用专用的工具,如"Resource Hacker", "Resource Extract" 和 "ExeScope"。这三个工具是Windows平台上广泛使用的资源管理工具,它们各自具有独特的功能和用途。 首先,Resource Hacker是一款强大的...
### Oracle 12c资源管理器(resource manager)详解 #### 一、Oracle 数据库资源管理器概述 在Oracle 12c中,资源管理器(Resource Manager)是一个强大的工具,它能够帮助管理员有效地管理数据库中的多个工作负载,...
在.NET框架中,资源文件(Resource Files)是用于存储应用程序中使用的各种静态数据,如文本字符串、图像、图标等的容器。C#项目通常会利用这些资源文件来管理多语言支持、图标和常量字符串,使得开发过程更加灵活且...
Windows Resource Kit Tools for Windows XP是一款专门为Windows XP系统设计的工具集,它包含了一系列用于系统管理、性能优化和故障排查的强大工具。这些工具为IT专业人员提供了深入理解操作系统内部机制的可能性,...