spring.messages.basename配置IP引发启动异常的技术问询

将spring.messages.basename配置为Spring Cloud Config Server的IP地址（示例配置如下）：

spring:
  messages:
    basename: http://1.2.3.4:8888/messages.properties 

应用启动时会尝试发送请求，但IP中的点被替换为斜杠，形成格式错误的URL：

http://1/2/3/4:8888/messages.properties

导致连接挂起无法正常启动。

调试发现问题出在org.springframework.boot.autoconfigure.context.MessageSourceAutoConfiguration.ResourceBundleCondition#getResources方法，该方法导致IP格式损坏。此外，应用中已自定义了名为messageSource的Bean（代码示例如下）：

@Bean(name = "messageSource")
public MessageSource messageSource(@Value("${spring.messages.basename:}") String basename) {
 ...
}

配置请求超时后应用可正常启动并加载正确消息。

技术问题 #

1. MessageSourceAutoConfiguration为何会尝试请求本该在类路径中的资源？
2. 当已存在自定义messageSource Bean时，MessageSourceAutoConfiguration是否仍应加载消息资源？
3. 如何禁用MessageSourceAutoConfiguration或消除格式错误的IP请求，无需配置超时？
4. 将spring.messages.basename设置为IP地址是否合法？

注：spring-boot版本为2.6.6，spring版本为5.3.18

1. MessageSourceAutoConfiguration为何会尝试请求本该在类路径中的资源？ #

MessageSourceAutoConfiguration中的ResourceBundleCondition会提前校验配置的basename对应的资源是否存在，它默认将basename视为类路径资源前缀，用点号作为路径分隔符拆分后拼接成类路径资源格式。当配置的是HTTP URL时，它误把IP里的点号当成类路径分隔符，将1.2.3.4拆分为1/2/3/4，生成错误URL并发起请求。

2. 当已存在自定义messageSource Bean时，MessageSourceAutoConfiguration是否仍应加载消息资源？ #

理论上不应该。Spring Boot自动配置遵循条件化加载原则，MessageSourceAutoConfiguration标注了@ConditionalOnMissingBean(name = "messageSource")，意味着容器中存在名为messageSource的Bean时，该自动配置类应完全失效。但实际出现的问题是，自动配置里的ResourceBundleCondition在Bean创建前就执行了资源检查逻辑，导致即使有自定义Bean，仍会触发错误的资源请求，这属于Spring Boot自动配置条件判断时机的边界问题。

3. 如何禁用MessageSourceAutoConfiguration或消除格式错误的IP请求，无需配置超时？ #

有两种可行方案：

• 直接禁用自动配置类：在启动类上添加@SpringBootApplication(exclude = MessageSourceAutoConfiguration.class)，彻底关闭该自动配置的所有逻辑，包括提前执行的资源检查。
• 调整配置规避检查：若不想完全禁用自动配置，可给spring.messages.basename配置添加classpath:前缀之外的标识，但这种方式稳定性不如直接禁用，毕竟你已经有自定义messageSourceBean，自动配置本身无存在必要。

4. 将spring.messages.basename设置为IP地址是否合法？ #

从Spring Boot官方设计来看，spring.messages.basename的默认用途是指定类路径下的资源文件前缀（比如messages对应messages.properties、messages_en.properties等），并不支持直接配置HTTP URL。虽然通过自定义messageSourceBean可实现远程加载消息资源，但该配置项的设计初衷不包含远程URL场景，这种用法属于非官方预期的扩展，不算标准合法的配置方式。

内容的提问来源于stack exchange，提问作者Hugh Bui