在Java / Maven中处理“Xerces hell”？

Question

在Java / Maven中处理“Xerces hell”？在我的办公室里，仅仅提到Xerces这个词就足以煽动开发者的凶悍愤怒。粗略地看一眼其他Xerces关于SO的问题似乎表明，几乎所有Maven用户都会在某个时候“触及”这个问题。不幸的是，理解这个问题需要对Xerces的历史有一点了解......历史Xerces是Java生态系统中使用最广泛的XML解析器。几乎每个用Java编写的库或框架都以某种身份使用Xerces（传递，如果不是直接的话）。包含在官方二进制文件中的Xerces罐子直到今天还没有版本化。例如，Xerces 2.11.0实现jar是命名的xercesImpl.jar而不是xercesImpl-2.11.0.jar。Xerces团队不使用Maven，这意味着他们不会将正式版本上传到Maven Central。Xerces曾经作为单个jar（xerces.jar）发布，但被分成两个jar，一个包含API（xml-apis.jar），另一个包含这些API的实现（xercesImpl.jar）。许多较旧的Maven POM仍然声明依赖xerces.jar。在过去的某个时刻，Xerces也被释放xmlParserAPIs.jar，一些较老的POM也依赖于它。分配给xml-apis和xercesImpl的版本由那些将其jar部署到Maven存储库的人通常是不同的。例如，xml-apis可能是1.3.03版本，而xercesImpl可能是2.8.0版本，即使两者都来自Xerces 2.8.0。这是因为人们经常使用它实现的规范版本来标记xml-apis jar。还有就是这是一个非常不错的，但不完全击穿这里。更复杂的是，Xerces是包含在JRE中的Java API for XML Processing（JAXP）的参考实现中使用的XML解析器。实现类在com.sun.*命名空间下重新打包，这使得直接访问它们很危险，因为它们可能在某些JRE中不可用。但是，并非所有Xerces功能都通过API java.*和javax.*API 公开; 例如，没有API公开Xerces序列化。几乎所有的servlet容器（JBoss，Jetty，Glassfish，Tomcat等）都会在一个或多个/lib文件夹中附带Xerces 。问题解决冲突对于上述某些原因（或许是全部原因），许多组织在其POM中发布和使用Xerces的自定义构建。如果你有一个小应用程序并且只使用Maven Central，这不是一个真正的问题，但它很快成为企业软件的问题，其中Artifactory或Nexus代理多个存储库（JBoss，Hibernate等）：例如，组织A可能发布xml-apis为：<groupId>org.apache.xerces</groupId><artifactId>xml-apis</artifactId><version>2.9.1</version>同时，组织B可能会发布jar如下：<groupId>xml-apis</groupId><artifactId>xml-apis</artifactId><version>1.3.04</version>虽然B的jar版本低于A版jar，但Maven并不知道它们是同一个版本，因为它们有不同 groupId的版本。因此，它无法执行冲突解决，并且两个 jars都将作为已解析的依赖项包含在内：Classloader Hell如上所述，JRE在JAXP RI中附带Xerces。虽然将所有Xerces Maven依赖项标记为<exclusion>s或as 会很好<provided>，您所依赖的第三方代码可能使用或不使用您正在使用的JDK的JAXP中提供的版本。此外，您还可以在servlet容器中附带Xerces jar以进行竞争。这给您留下了许多选择：您是否删除了servlet版本并希望您的容器在JAXP版本上运行？离开servlet版本是否更好，并希望您的应用程序框架在servlet版本上运行？如果上面列出的一个或两个未解决的冲突进入您的产品（很容易在大型组织中发生），您很快就会发现自己处于类加载器地狱，想知道类加载器在运行时选择的Xerces版本以及是否将在Windows和Linux中选择相同的jar（可能不是）。

Answer 1

坦率地说，我们遇到的几乎所有东西都适用于JAXP版本，所以我们总是排除 xml-apis和xercesImpl。