网站首页 全球最实用的IT互联网站!

人工智能P2P分享Wind搜索发布信息网站地图标签大全

当前位置:诺佳网 > 软件工程 > 后端开发 > Java >

【分享排雷经历】系统引入Apache-Tika产生的NoCla

时间:2025-08-07 23:30

人气:

作者:admin

标签:

导读:为实现文件导入的安全控制,在系统中引入了基于`Apache Tika`的文件类型校验机制。但在运行时出现`NoClassDefFoundError`,提示缺少`commons-io`类。经排查发现,`monorepo`依赖的`commons-io`版本(...

今天,我们的重点工作是对monorepo系统的文件导入做安全控制,主要是通过判断文件的扩展名和类型,来限定用户导入文件的合法性,防止非法文件进入系统造成风险。

我们借用了此前在另一个系统zfquan基于Apache Tika的解决方案。

不巧,在运行main程序时,出现了一个 NoClassDefFoundError 错误-未找到Apache Commons IO(commons-io)类库的一个class的定义

20:25:14.667 [main] DEBUG org.apache.tika.config.TikaConfig - loading tika config from defaults; no config file specified
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/io/input/UnsynchronizedByteArrayInputStream
	at org.apache.tika.config.TikaConfig.getDefaultMimeTypes(TikaConfig.java:317)
	at org.apache.tika.config.TikaConfig.<init>(TikaConfig.java:246)
	at org.apache.tika.config.TikaConfig.getDefaultConfig(TikaConfig.java:390)
	at org.apache.tika.Tika.<init>(Tika.java:119)
	at com.emax.zhenghe.common.util.TikaFileSecurityUtils.<init>(TikaFileSecurityUtils.java:20)
	at com.emaxcard.car.TestMain.main(TestMain.java:38)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.io.input.UnsynchronizedByteArrayInputStream
	at java.net.URLClassLoader.findClass(URLClassLoader.java:387)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
	... 6 more

Process finished with exit code 1

NoClassDefFoundError(而不是 ClassNotFoundException) 表示编译时类存在,但运行时找不到。

常见原因:

  • 依赖未正确引入。

  • 依赖冲突导致类加载失败。

  • 打包时遗漏了 commons-io.jar(如 maven-shade-plugin 未正确包含依赖)。



同样的Tika,为什么搬到monorepo就不行了呢?

经查maven依赖,monorepo系统与zfquan系统所依赖的 commons-io 的版本不同,zfquan2.16.1monorepo2.6,这导致了问题的发生。


与单体结构的zfquan所不同的是,monorepo是一个庞大的同时拥有基础lib库和上层应用的工程。我们是在lib库的 sby-component-dfs 包 中添加的Tika依赖。


我尝试在其中一个应用层pom里显式添加 commons-io:2.16.1,是可以解决问题的。

但,monorepo有多达数十个应用,我显然不能在这么多应用层里显式添加 commons-io:2.16.1 依赖。而且,这不符合我们的系统开发规范————maven包依赖统一在顶层pom来管理。


那么,如何继续解决呢?

通过应用的maven依赖树(dependency:tree)得知,commons-io:commons-io:jar:2.6 是直接作为顶层依赖引入的(没有被其他库传递依赖)

然后我在IDE中全局查找 <artifactId>commons-io</artifactId>,发现在顶层maven依赖管理文件 spring-base.pom 中,的确显式定义了 commons-io 的版本号!

<properties>
    ...
	<commons.version>2.6</commons.version>
</properties>

<dependencyManagement>
    <dependencies>
        ...
        <dependency>
            <groupId>commons-io</groupId>
            <artifactId>commons-io</artifactId>
            <version>${commons.version}</version>
        </dependency>
    </dependencies>
</dependencyManagement>

如此,我把这个版本号变更为 2.16.1 ,也是可以解决问题的。

但,monorepo项目庞大,这样可能会拆东墙补西墙————可能影响其他用到commons-io的系统功能。


so,我们得针对 Tika 版本来做文章,找到适配 commons-io:2.6 的版本。

DeepSeek很快给出答案:Tika 2.4.1依赖commons-io:2.6。开发者将 Tika 版本从 2.9.1 降级到 2.4.1,不再出现NoClassDefFoundError错误,并且经测试,这个版本的Tika可以满足我们对系统文件导入的安全控制。


当看到一些不好的代码时,会发现我还算优秀;当看到优秀的代码时,也才意识到持续学习的重要!--buguge
本文来自博客园,转载请注明原文链接:https://www.cnblogs.com/buguge/p/19027683


温馨提示:以上内容整理于网络,仅供参考,如果对您有帮助,留下您的阅读感言吧!
相关阅读
本类排行
相关标签
本类推荐

CPU | 内存 | 硬盘 | 显卡 | 显示器 | 主板 | 电源 | 键鼠 | 网站地图

Copyright © 2025-2035 诺佳网 版权所有 备案号:赣ICP备2025066733号
本站资料均来源互联网收集整理,作品版权归作者所有,如果侵犯了您的版权,请跟我们联系。

关注微信