Question

在DataSource文件中声明META-IF/context.xml并使用JNDI查找（方法1）从spring bean获取它，或者直接通过Spring声明DataSource之间是否有任何区别（方法2）如：

@Bean(destroyMethod = "close")
DataSource dataSource(Environment env) {
    HikariConfig dataSourceConfig = new HikariConfig();
    dataSourceConfig.setDriverClassName(env.getRequiredProperty(PROPERTY_NAME_DB_DRIVER_CLASS));
    dataSourceConfig.setJdbcUrl(env.getRequiredProperty(PROPERTY_NAME_DB_URL));
    dataSourceConfig.setUsername(env.getRequiredProperty(PROPERTY_NAME_DB_USER));
    dataSourceConfig.setPassword(env.getRequiredProperty(PROPERTY_NAME_DB_PASSWORD));

    return new HikariDataSource(dataSourceConfig);
}

我认为第二种方法更好，因为它不依赖于特定服务器，这意味着如果我们使用第一种方法并且有一天迁移到另一台服务器，我们必须调整第二台服务器中的上下文文件的策略（不是真的）？）。

由于

Answer 1

第一种方法的一些要点（容器中定义的DataSource的JNDI查找）：

可以在不触及实际应用程序的情况下进行配置
可以更好地保护敏感信息（如密码）
DataSource可以在同一服务器上的许多应用程序之间共享

我在需要时使用第一种方法来保证安全性（或＃34;安全性＆＃34;） - 通常，客户的要求是数据库访问的密码不得存储在应用程序中文本。对此的可能响应是，不会将密码存储在应用程序中，而是将其留给客户通过JNDI提供DataSource。

从系统管理的角度来看这也是有道理的 - 如果数据源需要重新配置，可能是由于某些基础设施或网络变化，所以它应该是管理员的权力（并且他们也有责任重新配置数据源。 servlet容器应该是这样的地方。

如果我不需要上述任何一种方法，我会使用第二种方法（不太复杂，更易于部署）。

Answer 2

如果有多个应用程序使用您的数据库。我们可以配置DataSource内部容器，而不是让每个应用程序管理其数据库配置，我们将让应用程序指向该共享配置。这也有助于您跨所有应用程序共享Db连接池。

原谅，我刚搜索在SO中找到类似的答案（否则我不会发布此答案）

当你必须在两者之间移动应用程序时，JNDI真的很棒   环境：开发到集成以测试到生产。如果你   配置每个应用服务器使用相同的JNDI名称，您可以拥有   每个环境中的不同数据库，而不必更改您的   码。您只需选择WAR文件并将其放入新文件中即可   环境。

以下是一些其他假设，这些假设在判断时至关重要   这个答案：

我无法访问部署代码的服务器   all，除了对日志的只读访问权限。写作和写作的人   包的代码与配置和管理的人不同   服务器。一旦WAR文件开始它的PROD之旅就不可能   再次改变而不回到开头。任何测试   如果更改了WAR，则必须重新执行QA在测试服务器上完成的操作。   也许你没有看到这个好处，因为你是一个孤独的开发者   在本地桌面上编写代码并部署生产权。

来源：Why use JNDI

通过tomcat上下文文件和spring上下文

2 个答案: