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。

这个类标识从classpath获得的资源。它会使用线程context的类加载器(class loader)、给定的类加载器或者用来载入资源的给定类。

如果类路径上的资源存在于文件系统里，这个 Resource 的实现会提供类似于java.io.File的功能。而如果资源是存在于还未解开(被servlet引擎或其它的环境解开)的jar包中，这些 Resource 实现会提供类似于java.net.URL 的功能。

ClassPathResource对象可以在Java代码中显式地使用ClassPathResource 构造函数来创建。但更多的是通过调用带表示路径的String参数的API函数隐式地创建。在后一种情况下，JavaBeans的 PropertyEditor 会分辨字符串中 classpath: 前缀，然后相应创建 ClassPathResource。

这是为处理 java.io.File 而准备的Resource实现。它既可以作为File提供，也可以作为URL。

这是为 ServletContext 资源提供的 Resource 实现，它负责解析相关web应用根目录中的相对路径。

它始终支持以流和URL的方式访问。 但是只有当web应用包被解开并且资源在文件系统的物理路径上时，才允许以 java.io.File 方式访问。是否解开并且在文件系统中访问，还是直接从JAR包访问或以其它方式访问如DB(这是可以想象的)，仅取决于Servlet容器。

这是为给定的 InputStream 而准备的 Resource 实现。它只有在没有其它合适的 Resource 实现时才使用。而且，只要有可能就尽量使用 ByteArrayResource 或者其它基于文件的Resource 实现。

与其它 Resource 实现不同的是，这是个 已经 打开资源的描述符-因此 isOpen() 函数返回 true。 如果你需要在其它位置保持这个资源的描述符或者多次读取一个流，请不要使用它。

这是为给定的byte数组准备的 Resource 实现。 它会为给定的byte数组构造一个 ByteArrayInputStream。

它在从任何给定的byte数组读取内容时很有用，因为不用转换成单一作用的 InputStreamResource。

application context构造器通常使用字符串或字符串数组作为资源(比如组成context定义 的XML文件)的定位路径。

当这样的定位路径没有前缀时，指定的 Resource 类型会通过这个路径来被创建并被用来载入bean的定义，这都取决于你所指定的application context。例如，如果你使用下面的代码来创建ClassPathXmlApplicationContext ：

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

这些Bean的定义会通过classpath载入并使用ClassPathResource。而如果你象下面这么创建FileSystemXmlApplicationContext：

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

这些Bean的定义会通过文件系统从相对于当前工作目录中被载入。

请注意如果定位路径使用classpath前缀或标准的URL前缀，那它就会覆盖默认的Resource 类型。因此下面的FileSystemXmlApplicationContext...

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

...实际上会通过classpath载入其bean定义。然而它仍是个FileSystemXmlApplicationContext。 如果后面它被当作ResourceLoader 来使用，那么任何没有使用前缀的路径依然会被当作一个文件系统路径。

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

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

Application context构造器中资源路径的值可以是简单的路径(就像上面的那样)，即一对一映射到一个目标资源； 或者可以包含特殊的"classpath*:"前缀和Ant风格的正则表达式(用Spring的 PathMatcher 工具来匹配)。 后面的二者都可以使用通配符。

该机制的一个用处就是做组件类型的应用组装。所有的组件都可以用通用的定位路径“发布”context定义片断， 这样当使用相同的 classpath*: 前缀创建最终的application context时，所有的组件片断都会被自动装入。

请注意，这个通配符只在application context构造器的资源路径中 (或直接在类的层次中使用 PathMatcher 工具时)有效， 它会在构造时进行解析。这与 Resource 类型本身没有关联。因为同一时刻只能指向一个资源，所以不能使用 classpath*: 前缀来构造实际的Resource。

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

4.7.2.2. classpath*: 前缀

当构造基于XML的application context时，路径字符串可能使用特殊的 classpath*: 前缀：

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

此前缀表示所有与给定名称匹配的classpath资源都应该被获取(其中，这经常会在调用 ClassLoader.getResources(...)) 时发生)，并接着将那些资源全并成最终的application context定义。

	Classpath*: 的可移植性
	带通配符的classpath依赖于底层classloader的 getResources() 方法。 现在大多数的应用服务器提供自己的classloader实现，它们在处理jar文件时的行为也许会有所不同。 要测试 classpath*: 是否有效，可以简单地用classloader从classpath中的jar文件里加载一个文件： getClass().getClassLoader().getResources("<someFileInsideTheJar>")。 针对两个不同位置但有相同名字的文件来运行测试。如果结果不对，那么就查看一下应用服务器的文档， 特别是那些可能影响classloader行为的设置。

"classpath*:"前缀也能在位置路径的其他部分结合PathMatcher pattern一起使用，例如"classpath*:META-INF/*-beans.xml"。在这里， 解析策略很简单：对最后一个非通配符路径片断使用一个ClassLoader.getResources()调用， 从类加载层次中获得所有满足的资源，随后针对子路径的通配符， 将同一个PathMatcher解析策略运用于每个资源之上。

    com/mycompany/package1/service-context.xml

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

一个并没有与 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");