"Java命名和目录接口"是一个使用层次模型访问目录的API。大多数Java开发人员从不使用它，而是用于广泛使用的JavaEE应用程序it.理论一个应用程序要使用服务器管理的资源（对于示例数据源），后者必须在JNDI中向应用程序公开。为了避免硬编码资源名，JavaEE定义了资源引用。在应用程序描述符中，大数据都学什么，您可以为应用程序所依赖的资源声明本地名称从开始一个JavaEE组件（webapp或EJB，用于完整的概要文件JavaEE），您可以访问本地JNDI上下文作为java：组件/环境"java"作为根说明符，因为您可以使用与JavaEE"component""env"相同的jndiapi来访问LDAP目录"comp"，javaee7引入了新的JNDI作用域，但是我们大多数人只会使用java:comp/env.During期间部署时，淘客单，应用服务器必须提供一种机制来将此引用绑定到实际的托管资源。因此，您可以将托管数据源"jdbc/monitoredOracleDb"绑定到组件资源引用"jdbc/mydb"。实践中坏消息是这种绑定没有标准化，我们以一个容器特定的描述符结束：WEB-INF/jboss-web.xml文件，WEB-INF/weblogic-web.xml文件更糟糕的是，这样的描述必须包含在战争中，因此，您必须了解生产环境的所有细节，双线服务器租用，并在这个额外的描述符中硬编码它们。您不能在登台和生产上部署相同的工件，云产品，除非它们对资源使用相同的内部名称，等等。那么开始JNDI地狱。出于某些显而易见的原因，当你向Tomcat JNDI请求"jdbc/foo"时，它会自动生成一个新的数据源，而不需要任何配置，最后你会得到一个神秘的"Cannot create jdbc driver of class'"For connect URL'null'。JBoss有自己的理解规范的方法：你的应用程序必须使用"jdbc/mydb"作为JNDI名称。如果你使用"java:comp/env/jdbc/mydb"正如标准告诉你的那样，它找不到它。所以，物联网，我们中的大多数人最终都会定义与webapp中使用的名称完全相同的内部资源，以避免此类问题。这使得SDK绑定完全无用。。直到你使用云蜂SDK.SDK开发包允许您将数据库绑定到应用程序并为其声明别名：bees应用程序：bind-dbmyaccount/mydatabase-a myaccount/myapp-as-dbmagic部分是最新的参数"as"。然后，应用程序将在JNDI上下文中以"jdbc/db"的形式公开数据源，您甚至不需要大多数应用程序服务器。这个这种方法只是让JNDI像它所设想的那样为javaee管理的资源工作收件人：这张图片来自Antonio Goncalves，Java EE专家组成员，绝对与这篇博文无关，未经他同意就被收录：PNicolas De Loof CloudBees