JDBC 驱动程序是否应该包含在 WAR 中？答案

【问题标题】：Should JDBC drivers be included in a WAR?JDBC 驱动程序是否应该包含在 WAR 中？
【发布时间】：2011-04-15 19:19:47
【问题描述】：

我们正在开发一个商业软件产品。它支持 Oracle、MySQL 和 SQL*Server 后端（我们也使用 H2 进行测试）。我们使用特定版本的 JDBC 驱动程序对那些不同的数据库进行集成测试。 Maven 完美地处理了这一切。

在将应用程序打包为 WAR 时，是否可以包含 JDBC 驱动程序？标准做法是什么？

由于我们不知道可以提前使用哪个数据库，因此我们必须将它们全部包含在内。目标 servlet 容器是 Tomcat 和 Jetty，但一些客户也希望在 WebSphere 和 JBoss 中运行。

所以 servlet 包含并且应用程序服务器带有它们自己的 JDBC 驱动程序？我们的会不会冲突？另一个问题是我们已经开发和测试了一个版本的驱动程序，如果客户使用另一个版本，我们可能会遇到问题。

目前我们使用 Spring 数据源 bean，但正在转向 JNDI 查找数据源。

【问题讨论】：

【解决方案1】：

除了将驱动程序包含在战争文件中的技术优点之外，您还应该检查驱动程序的许可并确保它可以由第三方分发。

【讨论】：

【解决方案2】：

所以 servlet 包含并且应用程序服务器带有它们自己的 JDBC 驱动程序？

有些可以（例如 WebLogic）。

我们的会冲突吗？

他们不应该。不过，不确定在应用程序级别创建独立连接池时是否会选择您的连接池（这完全取决于类加载器委托模式）。

另一个问题是我们已经开发和测试了一个版本的驱动程序，如果客户使用另一个版本，我们可能会遇到问题。

有支持的版本列表。

目前我们使用 Spring 数据源 bean，但正在转向 JNDI 查找数据源。

如果您的意思是使用应用程序服务器提供的连接池，则驱动程序必须安装在容器级别，而不是应用程序级别。这以某种方式结束了讨论。

【讨论】：

@Pascal Thivent：（与关于连接池的段落相关）您可以添加一些链接或解释一下吗？我同意你的观点（我按照你的描述做了几次，因为这是最直观的方式），但有人告诉我这是一种不好的做法（因为应用服务器和部署的应用程序中的相同库可能会导致冲突）和所有库都应该打包在应用程序的战争文件中。这对于在同一服务器上部署超过 1 个应用程序（在我的情况下为 tomcat）上的情况更为实际。
扩展最后一句话：JNDI 数据源是容器管理的，并且隐式要求驱动程序存在于容器的库中。容器不会扫描 WAR 库以查找驱动程序。这确实结束了讨论:)
@Roman 当然，请参阅Apache Tomcat 6.0 Class Loader HOW-TO。如果要使用Tomcat的内置连接池，驱动程序必须在$CATALINA_HOME/lib中，否则Tomcat将无法加载它。
这是一个更好的资源：@987654322@。请注意，它明确建议将驱动程序放在tomcat/lib。
@Pascal，BalusC：thanx，我从未使用过内置的 tomcats 连接池，但会知道是否需要这样做。

【解决方案3】：

在大多数应用程序中，JDBC 驱动程序不作为应用程序的一部分提供。

如果您确实发布了 JDBC 驱动程序，这意味着您必须为您想要支持的所有数据库提供驱动程序。它添加了很多不必要的库。

只是不要添加任何驱动程序，并告诉用户在需要时将相关的 JAR 文件放入服务器库中。

【讨论】：