jax-rs 自定义 `@provider`（如 `exceptionmapper`）在升级至 jboss eap 7 + jdk 11 后失效，主因是依赖作用域配置错误：关键 jakarta ee api（如 `javax.ws.rs-api`、`jaxb-api`）未声明为 `provided`，导致类加载冲突和注解不识别。
在 Jakarta EE 容器（如 JBoss EAP / WildFly）中，核心规范 API（如 JAX-RS、Bean Validation、JAXB）均由应用服务器自身提供并管理。若这些 API 被意外打包进应用 WAR/EAR（即 scope 未设为 provided），将引发两类严重问题：
- 注解失配：你的 @Provider 类使用的是应用内嵌的 javax.ws.rs.ext.Provider 注解（来自 javax.ws.rs-api-2.1.1.jar），而 JBoss 运行时扫描的是其自身 classloader 加载的 Provider 注解 —— 二者虽类名相同，但属于不同类加载器，不视为同一类型，因此 Provider 被完全忽略；
- 重复绑定冲突：多个版本的 API 共存可能导致 ExceptionMapper 注册失败、ConstraintViolationException 未被正确捕获，甚至引发 ClassCastException 或 NoClassDefFoundError。
✅ 正确的依赖配置（pom.xml 关键修正）
请将以下依赖的
javax.ws.rs javax.ws.rs-api 2.1.1 provided javax.xml.bind jaxb-api 2.3.1 provided org.jboss.resteasy resteasy-hibernatevalidator-provider 2.3.6.Final provided
? 补充说明： resteasy-jaxrs 和 validation-api 已正确设为 provided，无需改动； com.sun.xml.ws:rt 和 javax.xml.ws:jaxws-api 属于 JAX-WS，与 JAX-RS @Provider 无直接关联，保留当前配置即可，但建议评估是否真需在 REST 服务中启用 JAX-WS； JDK 11+ 不再包含 JAXB，但 JBoss EAP 7.3+ 内置了兼容的 resteasy-jaxb-provider，无需额外引入 jaxb-impl —— 若需 XML 支持，请确保 resteasy-jaxb-provider 在 standalone.xml 中已启用（默认开启）。
? 验证 Provider 是否注册成功
部署后，检查 JBoss 日志中是否有类似输出：
INFO [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 66) RESTEASY002225: Deploying javax.ws.rs.core.Application: class com.example.MyApplication INFO [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 66) RESTEASY002200: Adding provider class com.example.ValidationExceptionHandler from Application class com.example.MyApplication
若无此日志，说明 Provider 未被扫描到 —— 90% 概率是 @Provider 注解来源不匹配。
? 最佳实践建议
- ✅ 所有 javax.* / jakarta.* 规范 API 依赖（如 javax.ws.rs, javax.validation, javax.xml.bind）在容器环境中一律 scope=provided；
- ✅ 使用 mvn dependency:tree -Dincludes=javax.ws.rs,javax.xml.bind 确认无重复 API 打包；
- ✅ 迁移至 Jakarta EE 9+ 时，需将 javax.ws.rs.* 替换为 jakarta.ws.rs.*（注意 JBoss EAP 7 仍基于 Java EE 8 / javax.*，EAP 8+ 才支持 Jakarta）；
- ✅ 自定义 ExceptionMapper 应优先捕获更通用的异常（如 ConstraintViolationException），而非 MethodConstraintViolationException（后者是 Hibernate Validator 特定实现，可移植性差）。
修复依赖作用域后重新部署，ValidationExceptionHandler 即可被正常发现并响应校验异常 —— 这不是代码逻辑问题，而是模块隔离与类加载契约的根本遵循。
