为什么要将JNDI用于数据源 [英] Why use JNDI for data sources

问题描述

任何人都可以帮助解释为什么JNDI应该是公开数据库/ jms等服务的首选方式吗？

Can anyone help explain why JNDI should be a preferred way to expose services such as a database / jms?

我遇到的帖子都谈到了优势不必加载特定的驱动程序管理器，从连接池等方面获益，但可以通过在属性文件中指定驱动程序管理器并使用反射来轻松实现。

The posts I run into all talk about the advantage of not having to load a specific driver manager, benifiting from connection pooling etc. but thats easily achievable by specifying the driver manager in a properties file and using reflection.

连接池可以也可以通过弹簧或其他方式将正确的实现连接到应用程序bean中来实现。

Connection pooling can also be achieved by wiring in the right implementation into an application bean via spring or otherwise.

那么为什么使用JNDI会更好？

So why would using JNDI be any better?

推荐答案

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

JNDI really shines when you have to move an application between environments: development to integration to test to production. If you configure each app server to use the same JNDI name, you can have different databases in each environment and not have to change your code. You just pick up the WAR file and drop it in the new environment.

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

Here are some other assumptions that are crucial to know when judging this answer:

• 除了对日志的只读访问权限外，我根本无法访问部署代码的服务器。


• 编写和打包代码的人与配置和管理服务器的人不同。


• 一旦WAR文件启动到PROD，它就无法更改再次没有回到开头。如果WAR被更改，必须重新进行QA在测试服务器上完成的任何测试。

也许你看不到这个好处是因为您是一个单独的开发人员，他在本地桌面上编写代码并部署生产权。

Perhaps you don't see this benefit because you're a lone developer who writes code on a local desktop and deploys right to production.

这篇关于为什么要将JNDI用于数据源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！