Spring Boot Initializer生成WAR项目的ServletInitializer识别机制咨询

问题对应原始代码 #

主应用类 #

@SpringBootApplication
public class ChargingListenerApplication {

  public static void main(String[] args) {
    SpringApplication.run(ChargingListenerApplication.class, args);
  }

}

Servlet初始化器类 #

public class ServletInitializer extends SpringBootServletInitializer {

  @Override
  protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
    return application.sources(ChargingListenerApplication.class);
  }

}

1. Spring识别ServletInitializer并执行configure()的原理 #

这一机制基于Servlet 3.0+ 规范定义的SPI扩展能力：

• Servlet容器启动时会自动扫描classpath下META-INF/services/javax.servlet.ServletContainerInitializer文件中指定的实现类，Spring Web包中默认注册的实现是SpringServletContainerInitializer
• 该类上标注了@HandlesTypes(WebApplicationInitializer.class)，会通知容器把当前classpath下所有WebApplicationInitializer接口的实现类全部收集并传递给该类的onStartup方法
• 你写的ServletInitializer继承的SpringBootServletInitializer就是WebApplicationInitializer的抽象实现类，它的onStartup方法内部会调用你重写的configure()方法获取Spring应用配置源，完成上下文初始化。

2. 是否仅通过类的类型识别 #

是的，只要是WebApplicationInitializer接口的实现类，不管类名是什么、有没有加额外注解，只要在应用的classpath中，都会被Servlet容器自动识别并加载，不需要任何额外的标识配置。

3. 不使用专门注解的设计是否合理 #

这个设计是完全合理的，原因如下：

• 这套识别逻辑是Servlet 3.0规范的标准扩展流程，不是Spring自定义的规则，遵循规范可以保证应用在所有兼容Servlet 3.0+的容器中都能正常部署运行
• 基于类型的SPI加载不需要依赖Spring的注解扫描逻辑，在容器启动阶段就可以完成初始化，不需要等Spring上下文初始化完成，启动流程更顺畅，也避免了注解扫描可能带来的漏扫问题
• 不需要额外引入专属注解，降低了入侵性，也简化了用户的配置成本。

4. 主类继承和单独生成ServletInitializer的差异 #

两种写法功能上没有任何区别，最终都会被容器识别为合法的初始化类，差异仅在代码组织层面：

• 单独生成ServletInitializer类的写法符合单一职责原则，主应用类只负责内置容器启动的逻辑，Servlet容器部署的初始化逻辑单独拆分，方便后续扩展Servlet相关配置，维护性更好，也是Spring Initializr默认采用的最佳实践
• 主类直接继承SpringBootServletInitializer的写法更简洁，减少了类的数量，适合不需要额外自定义Servlet配置的简单场景。

内容的提问来源于stack exchange，提问作者Olgun Kaya