升级Tika 1.27后REPL正常、uberjar运行时Mime解析类型异常求助

问题根因 #

• 类加载优先级差异：Lein REPL环境按依赖声明顺序就近加载类，会优先加载你显式配置的javax.mail包下的MimeMessage实现；uberjar打包时会合并所有依赖的类文件，若同时存在jakarta.mail和javax.mail提供的同名javax.mail.internet.MimeMessage类，会按依赖权重覆盖类实现，导致打包后的MimeMessage逻辑和REPL环境不一致。
• Tika 1.27依赖变更：Tika 1.27版本默认引入jakarta.mail过渡依赖，而simplejavamail旧版本依赖javax.mail实现，两者的getContent逻辑存在差异：javax.mail版本会自动解析多部分内容返回MimeMultipart，jakarta.mail的兼容实现如果没有对应DataContentHandler注册，会直接返回原始SharedByteArrayInputStream输入流。
• SPI配置丢失：REPL运行时会动态加载所有依赖的SPI服务配置，javax.mail的content handler会被正常注册；uberjar打包时如果未合并META-INF/services下的同名SPI配置文件，会导致多个依赖的配置互相覆盖，MimeMultipart解析所需的handler未被注册，直接返回原始流。

修复方案 #

1. 统一MIME依赖实现，全局排除冲突 #

在project.clj中全局排除所有不一致的MIME过渡依赖，统一使用单一实现，推荐统一使用稳定的javax.mail 1.6.2版本，配置示例：

:dependencies [
  ;; 统一MIME依赖放在列表最顶部，优先加载
  [com.sun.mail/javax.mail "1.6.2"]
  ;; 排除Tika传递引入的jakarta.mail相关依赖
  [org.apache.tika/tika-parsers "1.27" :exclusions [jakarta.mail jakarta.activation]]
  ;; 排除simplejavamail传递引入的冲突MIME依赖
  [org.simplejavamail/simple-java-mail "你的版本号" :exclusions [javax.mail com.sun.mail/javax.mail]]
  ;; 其余依赖不变
]

2. 强制依赖冲突校验，避免隐式选择 #

在project.clj中添加pedantic配置，发现依赖冲突时直接终止构建，避免Leiningen自动选择未知版本：

:pedantic? :abort

3. 合并Uberjar的SPI配置 #

添加uberjar-merge-with配置，合并邮件解析所需的SPI配置文件，避免注册信息丢失：

:uberjar-merge-with {
  "META-INF/services/javax.activation.spi.MailcapRegistryProvider" [slurp str spit]
  "META-INF/services/javax.mail.util.StreamProvider" [slurp str spit]
  "META-INF/mailcap.default" [slurp str spit]
}

4. 快速兼容方案（可选） #

如果需要临时验证问题，可以在调用getContent后手动判断返回类型，输入流场景下手动转换为MimeMultipart：

(defn get-safe-content [^MimeMessage mime-msg]
  (let [content (.getContent mime-msg)]
    (if (instance? SharedByteArrayInputStream content)
      (MimeMultipart. (DataHandler. (ByteArrayDataSource. content (.getContentType mime-msg))))
      content)))

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