目录
一、问题描述
第一种情况
第二种情况
二、原因分析
第一种情况
第二种情况
三、解决方案
第一种情况
第二种情况
一、问题描述
以下都是在做ofd文件转换为pdf文件时报的错误，一共碰到了2种情况，我都记录了下来：
第一种情况
报错如下：
java.lang.NoClassDefFoundError: org/apache/commons/io/function/IOIterator
at org.ofdrw.reader.ZipUtil.unZipFileByApacheCommonCompress(ZipUtil.java:102)
at org.ofdrw.reader.OFDReader.<init>(OFDReader.java:139)
at org.ofdrw.converter.ConvertHelper.ofd2pdf(ConvertHelper.java:64)
at org.ofdrw.converter.ConvertHelper.toPdf(ConvertHelper.java:155)
at com.example.ofd.OfdApplicationTests.convertOfdToPdf(OfdApplicationTests.java:24)
at com.example.ofd.OfdApplicationTests.contextLoads(OfdApplicationTests.java:18)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
这是我当时引入的pom依赖：
<!-- OFD处理 -->
<dependency><groupId>org.ofdrw</groupId><artifactId>ofdrw-full</artifactId><version>2.3.3</version><exclusions><exclusion><artifactId>log4j-slf4j-impl</artifactId><groupId>org.apache.logging.log4j</groupId></exclusion></exclusions>
</dependency><!-- IO操作 -->
<dependency><groupId>commons-io</groupId><artifactId>commons-io</artifactId><version>2.11.0</version>
</dependency>第二种情况
报错如下：
java.lang.NoSuchMethodError: org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry()Lorg/apache/commons/compress/archivers/zip/ZipArchiveEntry;
at org.ofdrw.reader.ZipUtil.unZipFileByApacheCommonCompress(ZipUtil.java:104)
at org.ofdrw.reader.OFDReader.<init>(OFDReader.java:139)
at org.ofdrw.converter.ConvertHelper.ofd2pdf(ConvertHelper.java:64)
at org.ofdrw.converter.ConvertHelper.toPdf(ConvertHelper.java:155)
at com.example.ofd.OfdApplicationTests.convertOfdToPdf(OfdApplicationTests.java:24)
这是我当时引入的依赖：
<!-- OFD处理 -->
<dependency><groupId>org.ofdrw</groupId><artifactId>ofdrw-full</artifactId><version>2.3.3</version><exclusions><exclusion><artifactId>log4j-slf4j-impl</artifactId><groupId>org.apache.logging.log4j</groupId></exclusion></exclusions>
</dependency><dependency><groupId>org.apache.commons</groupId><artifactId>commons-compress</artifactId><version>1.21</version>
</dependency>二、原因分析
我把两种情况都进行了分析，大家一个个看。
第一种情况
点开源码溯源，定位到该行：
经过排查，发现我只要移除commons-io这个依赖后，这个报错就消失了，也就是说我们引入的common-io这个依赖和org.ofdrw冲突了，为什么会冲突呢？就是因为org.ofdrw这个依赖也引入了common-io，但是它引入的common-io依赖的版本和我们本地引入的不一致，所以才导致的报错，所以只需要把我们本地的common-io依赖版本改成和org.ofdrw引入的common-io依赖版本一致即可。
第二种情况
点开源码溯源报错行，得到如下截图：
意思就是说zipFile.getNextEntry()提供的方法应该来自ZipArchiveEntry这个类型，而我们实际提供的类型却是ArchiveEntry，类型不一致导致报的错，也是和第一种情况一样，需要更改我们的commons-compress依赖版本和org.ofdrw一致的就行。
三、解决方案
个人不推荐把本地的common依赖剔除，因为项目当中其他地方都用到了common依赖，所以推荐修改本地引入的common依赖版本来解决ofd转换报错的问题。
第一种情况
把commons-io这个依赖改成：
<dependency><groupId>commons-io</groupId><artifactId>commons-io</artifactId><version>2.16.1</version>
</dependency>即可完美解决报错。
第二种情况
把commons-compress这个依赖改成：
<dependency><groupId>org.apache.commons</groupId><artifactId>commons-compress</artifactId><version>1.27.1</version>
</dependency>