【问题标题】:How to avoid bcprov-jdk16-1.45.jar while running the application through POM entry通过POM入口运行应用程序时如何避免bcprov-jdk16-1.45.jar
【发布时间】:2018-04-05 23:21:18
【问题描述】:

我有一个在 Weblogic 12.1.3 中运行的 Java 8 应用程序。该应用程序使用 iText 5.5.9 并且所需的 BC 的最低版本是 1.49 。该应用程序在 Weblogic 中部署为 WAR 文件。我可以看到 war 文件具有正确版本的 BC 。但在运行时,它取自 WebLogic maven 插件路径并使用 BC 1.45。有什么方法可以通过编辑 POM 条目或编辑 WebLogic.xml 来避免这种情况。如果我从本地服务器中删除 BC 1.45 jar,它会成功运行。但我无法从更高的环境服务器中删除 jar。所以请帮忙。谢谢。

【问题讨论】:

  • 如果您摘录 POM 的相关部分并将其包含在您的答案中并进行相应的格式化,将会很有帮助。

标签: java itext bouncycastle


【解决方案1】:

这是一个已知问题。 BC 在版本之间破坏了他们的 API,当你的 CLASSPATH 中有两个不同的 BC 版本时,你会得到非常奇怪的错误(这可能会根据首先加载的版本而有所不同)。我看到您仍在使用旧的 iText(不是 iText 7),这意味着您可以切换到 iTextG。

iTextG 中的 G 代表 Google,创建 iTextG 是为了避免一些问题。例如:

  • 未列入白名单以在 GAE 或 Android 上使用的 Java 类已被删除,
  • 对在云环境中没有意义的特定文件操作进行了调整,
  • Bouncycastle 已替换为 SpongyCastle。

BouncyCastle 和 SpongyCastle 是相同的,除了它们的包名称和安全提供者的名称(“BC”与“SC”)。由于这些差异,两个不同的版本(例如 WebLogic 中的 BC 1.45 版和 iTextG 应用程序中的 SpongyCastle 1.49 版)不会发生冲突。

这是在 Android 上使用 iText 所必需的,因为 Android 附带旧版本的 BC(就像您的 WebLogic 附带旧版本一样)。

【讨论】:

  • 不仅包名在BC和SC之间改变了,安全提供者的名字也改变了。这对于允许 iTextG 访问 SpongyCastle 很重要!这也意味着在用 iTextG 替换 iText 后,OP 还必须将 SC 注册为安全提供者。
  • 好的,但是我们无法编辑 POM 以确保 BC jar 文件始终来自 lib 而不是来自 web-logic 服务器?
  • 但是像 provided 和 weblogic XML true 之类的 POM 中的那些标签呢?为什么这些在构建后没有任何效果
  • 根据 Bruno Lowagie 修改了代码,现在可以正常工作了。谢谢。
猜你喜欢
  • 2019-04-20
  • 1970-01-01
  • 2014-01-27
  • 2018-07-16
  • 1970-01-01
  • 1970-01-01
  • 2010-11-27
  • 1970-01-01
  • 2018-08-01
相关资源
最近更新 更多