🍊
翻译橙
🍊返回主站🤖参与贡献
  • hello,这里是翻译橙
  • spring boot参考文档
    • 1. 法律
    • 2. 寻求帮助
    • 3. 文档概述
    • 4. 入门
    • 5. 升级Spring Boot
    • 6. 使用 Spring Boot 进行开发
      • 6.1. 构建系统
      • 6.2. 构建你的代码
      • 6.3. 配置类
      • 6.4. 自动配置
      • 6.5. Spring Bean 和依赖注入
      • 6.6. 使用@SpringBootApplication注解
      • 6.7. 运行您的应用程序
      • 6.8. 开发者工具
      • 6.9. 打包您的生产应用程序
      • 6.10. 接下来读什么
    • 7.核心特性
      • 7.1. SpringApplication
      • 7.2. 外部化配置
      • 7.3.Profile配置
      • 7.4.日志记录
      • 7.5.国际化
      • 7.6 面向切面的编程
      • 7.7. JSON
      • 7.8. 任务执行与调度
      • 7.9. 单元测试
        • 7.9.1. 测试范围依赖
        • 7.9.2. 测试 Spring 应用程序
        • 7.9.3. 测试 Spring Boot 应用程序
        • 7.9.4. 测试容器
        • 7.9.5. 测试工具
      • 7.10. Docker Compose 支持
      • 7.11. 测试容器支持
      • 7.12. 创建您自己的自动配置
      • 7.13. Kotlin 支持
      • 7.14 SSL
      • 7.15.接下来要读什么
    • 8. 网络
      • 8.1. Servlet Web 应用程序
        • 8.1.1. “Spring Web MVC 框架”
        • 8.1.2. JAX-RS 和Jersey
        • 8.1.3. 嵌入式 Servlet 容器支持
      • 8.2 反应式网络应用程序
        • 8.2.1. “Spring WebFlux 框架”
        • 8.2.2. 嵌入式反应式服务器支持
        • 8.2.3. 反应式服务器资源配置
      • 8.3. 优雅关机
      • 8.4. spring安全
        • 8.4.1. MVC安全
        • 8.4.2. WebFlux 安全
        • 8.4.3. OAuth2
        • 8.4.4. SAML 2.0
      • 8.5. spring 会话
      • 8.6.GraphQL
      • 8.7. Spring HATEOAS
      • 8.8.接下来读什么
    • 9. 数据
      • 9.1. SQL数据库
      • 9.2. 使用 NoSQL 技术
      • 9.3. 接下来读什么
    • 10. 消息
      • 10.1. JMS
      • 10.2. AMQP
      • 10.3. Apache Kafka 支持
      • 10.4. Apache Pulsar 支持
      • 10.5. RSocket
      • 10.6. Spring Integration
      • 10.7. WebSockets
      • 10.8. What to Read Next
    • 11. IO
      • 11.1. 缓存
      • 11.2. Hazelcast
      • 11.3. Quartz 调度程序
      • 11.4. 发送电子邮件
      • 11.5. 验证
      • 11.6. 调用 REST 服务
      • 11.7. web services
      • 11.8. 使用 JTA 进行分布式事务
      • 11.9. 接下来读什么
    • 12. 容器镜像
  • Spring核心功能
    • 1.IOC容器和Bean简介
      • 1.2. 容器概述
      • 1.3. Bean概述
      • 1.4. 依赖项
        • 1.4.1. 依赖注入
        • 1.4.2. 详细的依赖关系和配置
        • 1.4.3. 使用depends-on
        • 1.4.4. 延迟初始化的 Bean
        • 1.4.5. 自动装配协作者
        • 1.4.6. 方法注入
    • 2. Resources
      • 2.1. 介绍
      • 2.2. Resource接口
      • 2.3. 内置Resource实现
      • 2.4. ResourceLoader接口
      • 2.5. ResourcePatternResolver接口
      • 2.6. ResourceLoaderAware接口
      • 2.7. 资源作为依赖
      • 2.8. 应用程序上下文和资源路径
    • 3. 验证、数据绑定和类型转换
      • 3.1. 使用 Spring 的 Validator 接口进行验证
      • 3.2. 将代码解析为错误消息
      • 3.3. Bean 操作和BeanWrapper
      • 3.4. spring类型转换
      • 3.5. spring字段格式
      • 3.6. 配置全局日期和时间格式
      • 3.7. Java Bean 验证
    • 4. SpEL表达式
    • 5. Spring 面向切面编程
      • 5.1. AOP 概念
      • 5.2. Spring AOP 的能力和目标
      • 5.3. AOP 代理
      • 5.4. @AspectJ 支持
        • 5.4.1. 启用@AspectJ 支持
        • 5.4.2. 声明一个切面
        • 5.4.3. 声明切入点
        • 5.4.4. 声明切点
        • 5.4.5. 切面说明
        • 5.4.6. 切面实例化模型
        • 5.4.7. AOP 示例
      • 5.5. 基于模式的 AOP 支持
      • 5.6. 选择要使用的 AOP 声明样式
      • 5.7. 混合切面类型
      • 5.8. 代理机制
      • 5.9. @AspectJ 代理的程序化创建
      • 5.10. 在 Spring 应用程序中使用 AspectJ
      • 5.11.更多资源
    • 6. Spring AOP API
      • 6.1. Spring中的切入点API
      • 6.2. Spring 中的 Advice API
      • 6.3. Spring 中的 Advisor API
      • 6.4. 使用ProxyFactoryBean创建 AOP 代理
      • 6.5. 简洁的代理定义
      • 6.6. 以编程方式创建 AOP 代理ProxyFactory
      • 6.7. 操作切面对象
      • 6.8. 使用“自动代理”工具
      • 6.9. 使用TargetSource实现
      • 6.10. 定义新的切面类型
    • 7. 空指针安全
    • 8. 数据缓冲器和编解码器
    • 9. 日志
    • 10. 附录
      • 10.1. XML 模式
      • 10.2. 自定义XML Schema
        • 10.2.1. 创作 Schema
        • 10.2.2. 编码一个NamespaceHandler
        • 10.2.3. 使用BeanDefinitionParser
        • 10.2.4. 注册处理程序和模式
        • 10.2.5. 在 Spring XML 配置中使用自定义扩展
        • 10.2.6. 更详细的例子
      • 10.3. 应用程序启动步骤
  • 使用redis实现分布式锁
  • Java 安全标准算法名称
  • JDK 9 JEP
  • JDK 10 JEP
  • 人件
    • 《人件》
    • 第一部分 管理人力资源
      • 01 此时此刻,一个项目正在走向失败
      • 02 干酪汉堡,做一个,卖一个
      • 03 维也纳在等你
      • 04 质量——如果时间允许
      • 05 再谈帕金森定律
      • 06 苦杏素
    • 第二部分 办公环境
      • 07 家具警察
      • 08 “朝九晚五在这里啥也完成不了。”
      • 09 在空间上省钱
      • 间奏曲:生产效率度量和不明飞行物
      • 10 大脑时问与身体时间
      • 11 电话
      • 12 门的回归
      • 13 采取保护步骤
    • 第三部分 正确的人
      • 14 霍恩布洛尔因素
      • 15 谈谈领导力
      • 16 雇一名杂耍演员
      • 17 与他人良好合作
      • 18 童年的终结
      • 19 在这儿很开心
      • 20 人力资本
    • 第四部分 高效团队养成
      • 21 整体大于部分之和
      • 22 黑衣团队
      • 23 团队自毁
      • 24 再谈团队自毁
      • 25 竞争
      • 26 一顿意面晚餐
      • 27 敞开和服
      • 28 团队形成的化学反应
    • 第五部分 沃土
      • 29 自我愈复系统
      • 30 与风险共舞
      • 3l 会议、独白和交流
      • 32 终极管理罪恶得主是……
      • 33 “邪恶”电邮
      • 34 让改变成为可能
      • 35 组织型学习
      • 36 构建社区
    • 第六部分 快乐地工作
      • 37 混乱与秩序
      • 38 自由电子
      • 39 霍尔加·丹斯克
由 GitBook 提供支持
在本页

这有帮助吗?

在GitHub上编辑
  1. Spring核心功能
  2. 2. Resources

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

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

2.8.1. 构建应用程序上下文

应用程序上下文构造函数(针对特定应用程序上下文类型)通常采用字符串或字符串数组作为资源的位置路径,例如构成上下文定义的 XML 文件。

当这样的位置路径没有前缀时,Resource从该路径构建并用于加载 bean 定义的特定类型取决于并适用于特定的应用程序上下文。例如,考虑以下示例,该示例创建一个 ClassPathXmlApplicationContext:

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

bean 定义是从类路径加载的,因为使用了ClassPathResource。但是,请考虑以下示例,该示例创建一个FileSystemXmlApplicationContext:

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

现在 bean 定义从文件系统位置加载(在这种情况下,相对于当前工作目录)。

请注意,在位置路径上使用特殊的类路径前缀或标准 URL 前缀会覆盖为加载 bean 定义而创建的默认资源类型。考虑以下示例:

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

使用FileSystemXmlApplicationContext从类路径加载 bean 定义。但是,它仍然是一个 FileSystemXmlApplicationContext。如果随后将其用作 ResourceLoader,则任何无前缀的路径仍将被视为文件系统路径。

构造ClassPathXmlApplicationContext实例——快捷方式

ClassPathXmlApplicationContext公开了许多构造函数以实现方便的实例化。基本思想是您可以仅提供一个字符串数组,该数组仅包含 XML 文件本身的文件名(没有前导路径信息),还可以提供一个Class. 然后ClassPathXmlApplicationContext从提供的类派生路径信息。

考虑以下目录布局:

com/
  example/
    services.xml
    repositories.xml
    MessengerService.class

以下示例显示了如何实例化由名为services.xml和 repositories.xml(位于类路径上)的文件中定义的 bean 组成的 ClassPathXmlApplicationContext 实例:

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

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

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

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

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

Ant样式的模式

路径位置可以包含 Ant 样式的模式,如以下示例所示:

/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 等),则会从中获取 java.io.File 并用于通过遍历来解析通配符文件系统。对于 jar URL,解析器要么从中获取 java.net.JarURLConnection,要么手动解析 jar URL,然后遍历 jar 文件的内容来解析通配符。

对可移植性的影响

如果指定的路径已经是一个文件 URL(无论是隐式的,因为基本ResourceLoader是一个文件系统,还是显式的),通配符保证以完全可移植的方式工作。

如果指定路径是位置,则解析器必须通过调用classpath获取最后一个非通配符路径段 URL 。Classloader.getResource()由于这只是路径的一个节点(不是末尾的文件),因此实际上未定义(在 ClassLoaderjavadoc 中)在这种情况下返回的 URL 类型。在实践中,它始终是java.io.File表示目录(类路径资源解析为文件系统位置的位置)或某种 jar URL(类路径资源解析为 jar 位置的位置)。尽管如此,此操作仍存在可移植性问题。

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

classpath*:前缀

在构建基于 XML 的应用程序上下文时,位置字符串可能会使用特殊classpath*:前缀,如以下示例所示:

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

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

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

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

与通配符有关的其他说明

请注意classpath*:,当与 Ant 样式模式结合使用时,仅在模式开始之前至少与一个根目录可靠地工作,除非实际的目标文件驻留在文件系统中。这意味着诸如classpath*:*.xml类的模式可能不会从 jar 文件的根目录中检索文件,而只能从扩展目录的根目录中检索文件。

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

如果要搜索的根包在多个类路径位置中可用,则不能保证具有classpath:资源的 Ant 样式模式找到匹配的资源。考虑以下资源位置示例:

com/mycompany/package1/service-context.xml

现在考虑一个可能有人用来尝试查找该文件的 Ant 样式路径:

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

这样的资源可能只存在于类路径中的一个位置,但是当使用诸如前面的示例之类的路径来尝试解析它时,解析器会处理 getResource("com/mycompany"); 返回的(第一个)URL; 。如果此基础包节点存在于多个 ClassLoader 位置,则所需的资源可能不存在于找到的第一个位置。因此,在这种情况下,您应该更喜欢使用 classpath*: 和相同的 Ant 样式模式,该模式会搜索包含 com.mycompany 基础包的所有类路径位置:classpath*:com/mycompany/**/service-context.xml。

2.8.3. FileSystemResource注意事项

未附加到 FileSystemResource 的 FileSystemApplicationContext(即,当 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.7. 资源作为依赖下一页3. 验证、数据绑定和类型转换

最后更新于1年前

这有帮助吗?

有关各种构造函数的详细信息,请参阅 javadoc。

类路径包的扫描需要类路径中存在相应的目录条目。使用 Ant 构建 JAR 时,不要激活 JAR 任务的files-only开关。此外,根据某些环境中的安全策略,类路径目录可能不会暴露——例如,JDK 1.7.0_45 及更高版本上的独立应用程序(这需要在清单中设置“可信库”。请参阅 )。在 JDK 9 的模块路径(Jigsaw)上,Spring 的类路径扫描通常按预期工作。在这里也强烈建议将资源放入专用目录,避免上述搜索 jar 文件根级别的可移植性问题。

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