Jersey/HK2/Vaadin项目未使用Hadoop报winutils缺失异常处理

完全不需要下载winutils.exe组件。当前的启动报错、WADL文件中出现未声明的HDFS资源条目，本质是Jersey的类扫描逻辑误加载了类路径下冗余的Hadoop传递依赖。从根源上隔离或排除这些无用依赖即可同时解决两个问题，下载winutils.exe仅能临时消除启动报错，既无法移除WADL中的多余资源，还会让无用的Hadoop组件持续在运行时加载，带来不必要的性能开销。

• Jersey默认的服务端类扫描机制，会遍历扫描范围内的所有类，自动识别带JAX-RS注解的类并注册为REST资源
• 当前类路径中存在的hadoop-common-2.7.4、hadoop-hdfs-2.7.4，自带了一套完整的基于JAX-RS实现的HDFS Web管理接口，完全符合Jersey的扫描识别规则
• 这些被误捕获的Hadoop类在初始化时，会触发Hadoop本地文件系统组件的加载逻辑，Windows环境下找不到winutils.exe就会抛出对应报错；这些不属于项目自身的HDFS接口，也就直接被收录到了生成的application.wadl文件中

方案1：从依赖层面彻底排除冗余Hadoop组件（推荐） #

• 执行Maven依赖查询命令，定位hadoop组件的实际引入路径：mvn dependency:tree -Dincludes=org.apache.hadoop
• 找到hadoop-common、hadoop-hdfs的上游引入依赖后，在对应依赖的<exclusions>节点下，精准排除所有org.apache.hadoop包下的传递依赖
• 排除完成后重新打包部署，确认WEB-INF/lib目录下无hadoop相关jar包，从根源上让Jersey无法扫描到冗余的HDFS资源类

注意：不要不查引入路径直接硬删hadoop坐标，避免误删其他组件运行必需的依赖逻辑

方案2：收窄Jersey的类扫描范围（适配无法直接排除依赖的场景） #

如果因为依赖链路限制暂时无法直接移除Hadoop组件，可以修改Jersey的扫描逻辑，只扫描项目自身存放REST接口代码的包，避免遍历到第三方库的类：

• 如果你使用代码方式配置Jersey应用，重写getPackages()方法，仅返回自身REST接口所在的包路径，示例：

@Override
public Set<String> getPackages() {
    return Collections.singleton("com.your.project.rest");
}

• 如果你在web.xml中配置Jersey Servlet，修改初始化参数jersey.config.server.provider.packages的值，将其设置为自身REST接口的包路径，不要配置为空白、根包（如com、org）这类会覆盖第三方库的范围
• 同步收窄HK2的自动扫描范围，避免HK2在依赖注入初始化阶段主动加载Hadoop相关的类

• 不要为了消报错盲目下载winutils.exe，该操作不会移除WADL中的多余HDFS资源，也无法避免Hadoop类初始化带来的其他潜在运行时异常
• 检查扫描配置时，注意避免配置的包路径覆盖到第三方依赖的包名，比如自身项目包名是com.xxx，就不要把扫描范围设为com根路径，否则还是会扫描到类路径下所有com开头的第三方JAX-RS类
• 本地IDE部署时注意核对依赖加载的目录，避免因为之前的残留jar包，导致Maven排除依赖后依然能被扫描到

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