Spring Boot2.7.x中spring-boot-starter-jetty为何依赖tomcat-embed-el

这个依赖不是Jetty本身的传递依赖，是Spring Boot starter的默认依赖选型逻辑导致的，核心原因如下：

• 独立版Jetty对表达式语言（EL）实现做了松耦合设计，本身不强制绑定特定厂商的EL实现，只要是符合JSR-341（javax.el 3.0）规范的实现都可以兼容接入，因此官方独立安装包不会硬编码引入Tomcat的EL组件，用户可以按需自行选择EL实现。
• Spring Boot的starter设计目标是零配置开箱即用，官方会为所有starter固定一套经过全场景兼容性验证的依赖组合，避免用户自行选择组件版本出现类缺失、版本冲突、行为不一致的问题。在2.7.x版本的依赖管理规则中，tomcat-embed-el是Spring Boot全局指定的默认EL实现：不管你选择Tomcat、Jetty还是Undertow作为嵌入式Servlet容器，默认都会引入这个组件，保证JSP解析、Spring标签表达式解析、注解值表达式解析等依赖EL能力的功能可以直接正常运行。
• 你在依赖树里看到的tomcat-embed-el，不是Jetty相关组件传递引入的，是spring-boot-starter-jetty本身直接声明的依赖。Spring Boot在做容器切换的依赖设计时，只排除了tomcat-embed-core、tomcat-embed-websocket这类和Tomcat容器核心强绑定的组件，刻意保留了tomcat-embed-el：跨容器场景下统一使用同一个EL实现，可以避免不同厂商EL实现的行为差异导致的隐性兼容bug。

如果你确定项目不需要JSP支持，也没有使用任何依赖javax.el规范做表达式解析的功能，可以直接在构建配置中排除这个依赖，不会影响Jetty容器本身的正常启动运行。Maven配置示例如下：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-jetty</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.apache.tomcat.embed</groupId>
            <artifactId>tomcat-embed-el</artifactId>
        </exclusion>
    </exclusions>
</dependency>

排除后建议做一次全功能回归测试，确认没有用到EL相关能力的场景报错即可。

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