Spring资源篇(二)(完结)——ApplicationContext与资源路径

ApplicationContext与资源路径

1.构造ApplicationContext

ApplicationContext构造器通常使用一个字符串或大量字符串作为构造context定义的资源（eg：xml）的位置路径。

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

note："conf/appContext.xml"作为ClassPathResource被使用，即bean定义将会从classpath中被加载。

ps：当没有前缀的字符串作为资源载入时，Resource的类型依赖于特定的ApplicationContext。

eg：ClassPathXmlApplicationContext获取的Resource的类型为ClassPathResource。

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

note：classpath前缀令默认使用的FileSystemResource被ClassPathResouce重载。

ps：指定特定的前缀将会重载默认的Resource类型，不过，如果还继续作为ResourceLoader加载资源，它仍会使用默认的Resource加载无前缀的位置路径。

构造ClassPathXmlApplicationContext实例的捷径

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

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

ps：ClassPathXmlApplicationContext可以通过使用仅包含文件名（不包含路径）的String数组以及一个指定的class构造ClassPathXmlApplicationContext实例，这个指定类的路径将作为被加载文件的路径。

2.ApplicationContext构造器资源路径中的通配符

ApplicationContext的构造器的资源路径值可以是能与目标Resource一对一映射的简单路径，也可以包含特定的"classpath*:"前缀或内部Ant风格正则表达式（使用Spring的PathMatcher工具匹配）。

通配符机制的一个应用是将组件风格的应用组装。

所有的组件可以将context定义片段全部都公布到一个well-konwn路径下。最终的ApplicationContext将会使用相同的前缀"classpath*:"创建，这样，所有的组建片段都可以被自动选出。

通配符是ApplicationContext构造器的特殊使用，将会在构造期间被解析。

classpath*:前缀本身不能用于构造实际的Resource，因为一个Resource一次只会指向一个资源。

Ant风格模式

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

note：包含Ant风格模式的路径位置。

解析者通过一个复杂但明确的过程来试图解析通配符。

解析者为直到最后无通配符部分的路径产生一个Resource，并以此获得一个URL。

如果URL不是一个jar:URL或者容器特定URL（eg：WebLogic中的zip:，WebSphere的wsjar等），一个java.io.File将会从中获取，然后通过遍历文件系统解析通配符。

如果URL是一个jar URL，解析器要么从中获取一个java.net.JarURLConnection要么手动解析jar URL，然后遍历jar文件内容解析通配符。

对移植的影响

如果指定的路径是一个fileURL，通配符将会以完全移植的方式工作。

如果指定的路径是一个classpath位置，解析者将会通过Classloader.getResource()方法获取最终无通配符部分的URL。

由于这个URL只是节点的路径，所以返回的URL类型实际上是未定义的。

事实上，返回的URL通常是代表目录的java.io.File，或者某些jar URL。

不过，这个操作存在移植性问题。

如果获得的URL类型是jar URL，URL必需通过java.net.JarURLConnection或手动解析方式，以jar文件内容解析通配符。

以上行为在某些环境下可能会失败，所以推荐对来自jar文件资源进行解析时，在环境上先进行彻底的测试。

classpath*:前缀

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

ps：classpath*:前缀规定所有匹配给定名字的classpath资源全部会被获取，然后合并形成最终的ApplicationContext定义。

ps：这一方法通过ClassLoader.getResources()实现。

由于现在大多数的应用服务器都会提供自己的classloader实现，所以当处理jar文件时，行为会出现差异。

在路径的剩余部分，classpath*:前缀可以与PathMatch模式结合

在这种情况下，解析策略非常简单：调用ClassLoader.getResouces()获取类加载器层次的全部映射资源，然后使用PathMatcher解析策略对每一个通配符子路径进行处理。

关于通配符的注意

当classpath*与Ant-style模式结合时，在模式启动之前，至少需要一个根目录，这样解析才能可靠运行，除非实际目标文件就位于文件系统。

类似于classpath*:*xml的模式不会检索jar文件根下的文件，只会检索根目录。

Spring检索classpath的能力源于ClassLoader.getResource()方法。

Spring会求得URLClassLoader运行时配置与jar文件中的"java.class.path"manifest，不过这并不保证可靠的移植行为。

如果用于查找的根目录有多个类路径位置，与classpath:搭配使用的Ant-style模式资源并不保证找到映射文件。

资源位置为com/mycompany/package1/service-context.xml

使用路径为classpath:com/mycompany/**/service-context.xml

进行解析时，会得到通过getResource("com/mycompany")返回的第一个URL。如果这个基础包节点位于多个类加载器位置，那么实际终端资源就有可能不在得到的URL之下。

所以，最好使用classpath*:与Ant风格模式搭配的方式用于上述例子，这样便可以检索所有的类路径位置。

3.FileSystemResource警告

FileSystemApplicationContext强制令FileSystemResource实例将所有的位置路径全部作为相对路径进行处理，无论是否以前斜杠开头。

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

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

note：以上两者等价。

如果确实需要使用绝对文件系统路径，可以通过使用file:前缀强制使用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");