Spring5参考指南
  • 简介
  • 前言
    • 1. “Spring”代表什么
    • 2. Spring和Spring框架的历史
    • 3. 设计哲学
    • 4. 反馈和贡献
    • 5. 开始
  • 核心技术
    • 1. IoC容器
      • 1.1 IoC容器和Beans介绍
      • 1.2 IoC容器概述
      • 1.3 Bean概述
      • 1.4 依赖
      • 1.5 Bean作用域
      • 1.6 自定义Bean
      • 1.7 Bean的继承
      • 1.8 容器扩展点
      • 1.9 基于注解的容器配置
      • 1.10 类路径扫描和托管组件
      • 1.11 使用JSR 330标准注解
      • 1.12 基于Java的容器配置
      • 1.13 环境抽象
      • 1.14 注册LoadTimeWeaver
      • 1.15 ApplicationContext的其他功能
      • 1.16 BeanFactory
    • 2.资源
      • 2.1介绍
      • 2.2资源接口
      • 2.3内置资源实现
      • 2.4ResourceLoader
      • 2.5ResourceLoaderAware接口
      • 2.6资源作为依赖
      • 2.7应用程序上下文和资源路径
    • 3.验证,数据绑定,和类型转换
      • 3.1使用Spring Validator接口
      • 3.2将代码解析为错误消息
      • 3.3bean操作和BeanWrapper
      • 3.4Spring类型转换
      • 3.5Spring字段格式化
      • 3.6配置全局Date和Time格式
      • 3.7Spring验证
    • 4.SpEL Spring表达式语言
      • 4.1求值
      • 4.2bean定义中的表达式
      • 4.3语言引用
    • 5.Spring AOP
      • 5.1什么是AOP
      • 5.1Spring AOP的能力和目标
      • 5.3AOP代理
      • 5.4@AspectJ 支持
      • 5.5基于Schema的AOP支持
      • 5.6选择要使用的AOP声明样式
      • 5.7混合Aspect类型
      • 5.8代理机制
      • 5.9程序创建@AspectJ代理
      • 5.10在Spring应用程序中使用AspectJ
      • 5.11更多资源
    • 6.Spring AOP APIs
      • 6.1Pointcut API
      • 6.2Advice API
      • 6.3Advisor API
      • 6.4使用ProxyFactoryBean来创建AOP代理
      • 6.5简介的代理定义
      • 6.6使用ProxyFactory创建AOP代理
      • 6.7操作被通知的对象
      • 6.8使用auto-proxy功能
      • 6.9使用TargetSource的实现
      • 6.10定义新的Advice Types
    • 7.Null-safety
    • 8.数据缓存和解码器
    • 9.附录
      • 9.1XML Schemas
      • 9.2创建XML Schemas
  • 测试
    • 1.Spring测试介绍
    • 2.单元测试
      • 2.1Mock Objects
      • 2.2单元测试支持类
    • 3.集成测试
      • 3.1概览
      • 3.2集成测试的目的
      • 3.3JDBC测试支持
      • 3.4注解
      • 3.5Spring TestContext框架
      • 3.6Spring MVC测试框架
      • 3.7WebTestClient
    • 4.更多资源
  • 数据访问
    • 1.事务管理
    • 2.DAO支持
    • 3.JDBC
      • 3.1选择JDBC数据库访问方法
      • 3.2包层次结构
      • 3.3使用JDBC核心类控制基本JDBC处理和错误处理
      • 3.4控制数据库连接
      • 3.5JDBC批处理操作
      • 3.6使用SimpleJdbc
      • 3.7将JDBC操作建模为Java对象
      • 3.8参数和数据值处理的常见问题
      • 3.9嵌入式数据库支持
      • 3.10初始化数据源
    • 4.ORM
      • 4.1Spring ORM介绍
      • 4.2ORM集成的一般注意事项
      • 4.3Hibernate
      • 4.4JPA
    • 5.使用Object-XML映射封装XML
  • Web Servlet
    • 1. Spring Web MVC
      • 1.1 DispatcherServlet
      • 1.2 Filters
      • 1.3 Controllers注解
      • 1.4 URI链接
      • 1.5 异步请求
      • 1.6 CORS
      • 1.7 Web Security
      • 1.8 HTTP Caching
      • 1.9 View技术
      • 1.10 MVC配置
      • 1.11 HTTP/2
    • 2. REST客户端
    • 3. 测试
    • 4. WebSockets
      • 4.1 WebSocket介绍
      • 4.2 WebSocket API
      • 4.3 SockJS Fallback
      • 4.4 STOMP
  • Web Reactive
    • 1.Spring WebFlux
      • 1.1 Overview
      • 1.2 Reactive Core
      • 1.3 DispatcherHandler
      • 1.4 Annotated Controllers
      • 1.5 Functional Endpoints
      • 1.6 URI Links
      • 1.7 CORS
      • 1.8 Web Security
      • 1.9 View Technologies
      • 1.10 HTTP Caching
      • 1.11 WebFlux Config
      • 1.12 HTTP/2
    • 2.WebClient
    • 3.WebSockets
    • 4.测试
    • 5.Reactive库
由 GitBook 提供支持
在本页
  • 2.7.1 构造Application Contexts
  • 2.7.2 应用程序上下文构造函数资源路径中的通配符
  • 2.7.3 FileSystemResource注意事项

这有帮助吗?

  1. 核心技术
  2. 2.资源

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

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

2.7.1 构造Application Contexts

application context constructor(特定context类型)通常使用string或者string数组作为resources路径的地址,比如定义context 的XML地址。

如果该地址没有前缀,那么该定义bean定义的Resource将会依赖于和他最相近的application context.比如下面的例子会使用ClassPathXmlApplicationContext:

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

这个bean定义将会从classpath加载,因为ClassPathResource被使用。但是下面的例子将会创建FileSystemXmlApplicationContext:

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

现在bean定义从文件系统加载。

如果加上前缀,那么将会覆盖默认的Resource类型。如下:

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

这里虽然使用了FileSystemXmlApplicationContext,但是还是会从classpath中加载。但是如果在后面的代码中,还有需要使用到ResourceLoader的, 那么没有前缀的paths仍然会被认为是filesystem路径。

构造ClassPathXmlApplicationContext-快捷方式

ClassPathXmlApplicationContext公开了许多构造函数,以方便实例化。基本思想是,你只需提供一个字符串数组,该数组只包含XML文件本身的文件名(不包含前导路径信息),还提供一个类。然后,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);

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

应用程序上下文构造函数值中的资源路径可以是简单路径(如前所示),每个路径都有到目标资源的一对一映射,或者可以包含特殊的“classpath*:”前缀或内部ant样式正则表达式(通过使用Spring的PathMatcher实用程序)。后者都是有效的通配符。

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

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

Ant-style Patterns

下面是 Ant-style patterns 的路径:

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

当路径位置包含一个Ant样式的模式时,解析器将遵循一个更复杂的过程来尝试解析通配符。它为最后一个非通配符段的路径生成一个资源,并从中获取一个URL。如果该URL不是jar:URL或容器特定的变量(例如,weblogic中的zip、websphere中的wsjar等),则从该URL获取java.io.File,并通过遍历文件系统来解析通配符。对于JAR URL,解析器要么从中获取java.net.JarURLConnection,要么手动解析JAR URL,然后遍历JAR文件的内容以解析通配符。

对可移植性的影响

如果指定的路径已经是一个文件URL(或者隐式地因为ResourceLoader是一个文件系统,或者显式地指定),则通配符是完全可移植的。

如果指定的路径是类路径位置,解析程序必须通过调用ClassLoader.getResource()获取最后一个非通配符路径段URL。因为这只是路径的一个节点(而不是文件的末尾),所以实际上(在类加载器JavaDoc中)没有定义在这种情况下返回的具体URL类型。实际上,它始终是一个java.io.File,表示目录(类路径资源解析为文件系统位置)或某种类型的JAR URL(类路径资源解析为JAR位置)。尽管如此,这个操作还是存在可移植性问题。

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

classpath*:前缀

构造基于XML的application context,路径地址可以使用classpath*: 前缀,如下:

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

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

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

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

通配符的其他关注点

注意,当与Ant样式模式结合使用时,除非实际目标文件位于文件系统中,否则classpath_: 在模式开始之前只能在至少有一个根目录的情况下可靠的执行。这意味着classpath_:*.xml等模式可能不会从jar文件的根目录中检索文件,而是只从扩展目录的根目录中检索文件。

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

Ant-style 模式classpath: resources 并不一定能保证匹配的资源,如果要搜索的根package存在于多个类路径地址中。考虑下面的资源情况:

com/mycompany/package1/service-context.xml

下面是可能用到的Ant-style path 匹配:

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

这样的资源只能位于一个位置,但是当使用前面的示例这样的路径来尝试解析它时,解析程序将使用getResource(“com/mycompany”);返回的(第一个)URL。如果此基本包节点存在于多个类加载器位置中,则实际的最终资源可能找不到。因此,在这种情况下,你应该更喜欢使用具有相同ant样式模式的classpath*:来搜索包含根包的所有类路径位置。

2.7.3 FileSystemResource注意事项

未连接到FileSystemApplicationContext的FileSystemResource(即,当FileSystemApplicationContext不是实际的ResourceLoader时)会按预期处理绝对和相对路径。相对路径相对于当前工作目录,而绝对路径相对于文件系统的根目录。

但是,由于向后兼容性(历史)的原因,当FileSystemApplicationContext是ResourceLoader时,这一点会发生变化。FileSystemApplicationContext强制所有附加的FileSystemResource实例将所有位置路径视为相对路径,不管它们是否以前导斜杠开头。实际上,这意味着以下示例是等效的:

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

ApplicationContext ctx =
    new FileSystemXmlApplicationContext("/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 its definition via a UrlResource
ApplicationContext ctx =
    new FileSystemXmlApplicationContext("file:///conf/context.xml");
上一页2.6资源作为依赖下一页3.验证,数据绑定,和类型转换

最后更新于3年前

这有帮助吗?

扫描classpath包需要在classpath中存在相应的目录。当你使用Ant构建JAR时,不要激活JAR任务的“仅文件”开关。此外,根据某些环境中的安全策略,类路径目录可能不会被公开-例如,JDK 1.7.0 U45及更高版本上的独立应用程序(需要在清单中设置“可信库”)。请参阅 在JDK9的模块路径(Jigsaw)上,Spring的类路径扫描通常按预期工作。在这里,将资源放入一个专用的目录也是非常推荐的,这样可以避免前面提到的在搜索JAR文件根级别时的可移植性问题。

https://stackoverflow.com/questions/19394570/java-jre-7u45-breaks-classloader-getresources)。