JNDI初探之tomcat的datasource配置

原创 2016年04月14日 14:10:57

有人说:没有掌握JNDI就没有真正的理解JavaEE。
看来我一直都没理解呀!

JavaEE 的角色

在聊JNDI之前,我们先讨论一下JavaEE的角色吧。
J2EE 规范把职责委托给多个开发角色:组件提供者(Component Provider)、应用程序组装者(Application Assembler)、部署人员(Deployer)和系统管理员(System Administrator)。

组件提供者 这个角色负责创建 J2EE 组件,J2EE 组件可以是 Web 应用程序、企业级
JavaBean(EJB)组件,或者是应用程序客户机(例如基于 Swing 的 GUI 客户机应用程序)。组件提供者包括:HTML
设计师、文档编程人员以及其他开发人员角色。大多数 J2EE 开发人员在组件提供者这一角色上耗费了相当多的时间。 应用程序组装者
这个角色将多个 J2EE
模块捆绑成一个彼此结合的、可以部署的整体:企业归档(EAR)文件。应用程序组装者要选择组件,分清它们之间的交互方式,配置它们的安全性和事务属性,并把应用程序打包到
EAR 文件中。许多 IDE,例如 WebSphere® Studio、IDEA、JBuilder、WebLogic Workshop
和其他 IDE,都可以帮助应用程序组装者以交互方式配置 EAR 文件。 部署人员(Deployer) 这个角色负责部署,这意味着将 EAR
安装到 J2EE
容器(应用服务器)中,然后配置资源(例如数据库连接池),把应用程序需要的资源绑定到应用服务器中的特定资源上,并启动应用程序。
系统管理员(System Administrator) 这个角色负责保证容器需要的资源可用于容器。

外部资源的后绑定

任何不平凡(nontrivial)的 J2EE 应用程序都需要访问描述它期望使用环境的信息。这意味着开发和测试组件时,为了临时测试代码,开发人员要承担一些部署方面的职责。重要的是要理解:这么做的时候,您就走出了开发人员的领域。否则,可以试着依靠 JDBC 驱动程序,或 URL、JMS 队列名称,或者其他具有无意识的、偶尔可能是灾难性暗示的机器资源。

什么是JNDI

命名和目录接口,Java Naming and Directory Interface。
为什么会有jndi?
jndi诞生的理由似乎很简单。随着分布式应用的发展,远程访问对象访问成为常用的方法。虽然说通过 Socket等编程手段仍然可实现远程通信,但按照模式的理论来说,仍是有其局限性的。RMI技术,RMI-IIOP技术的产生,使远程对象的查找成为了技术焦点。JNDI技术就应运而生。JNDI技术产生后,就可方便的查找远程或是本地对象。
这里写图片描述
许多开发人员知道:代码和外部资源之间的紧密耦合是潜在的问题,但是在实践中却经常忘记角色的划分。在小型开发工作中(指的是团队规模或部署规模),即使忽视角色划分也能获得成功。
J2EE 规范要求所有 J2EE 容器都要提供 JNDI 规范的实现。JNDI 在 J2EE 中的角色就是“交换机” —— J2EE 组件在运行时间接地查找其他组件、资源或服务的通用机制。在多数情况下,提供 JNDI 供应者的容器可以充当有限的数据存储,这样管理员就可以设置应用程序的执行属性,并让其他应用程序引用这些属性(Java 管理扩展(Java Management Extensions,JMX)也可以用作这个目的)。JNDI 在 J2EE 应用程序中的主要角色就是提供间接层,这样组件就可以发现所需要的资源,而不用了解这些间接性。

举个例子

典型的数据源配置,我就不举例子了,你肯定知道。
那,怎么用JNDI来配置呢?让开发和部署分隔开。
以tomcat为例:

server.xml

<GlobalNamingResources>
    <!-- Editable user database that can also be used by
         UserDatabaseRealm to authenticate users
    -->
    <Resource name="UserDatabase" auth="Container"
              type="org.apache.catalina.UserDatabase"
              description="User database that can be updated and saved"
              factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
              pathname="conf/tomcat-users.xml" />
    <Resource  
        name="jdbc/mysql"   
        scope="Shareable"   
        type="javax.sql.DataSource"  
        factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory"  
        url="jdbc:mysql://localhost:3306/armstrong"  
        driverClassName ="com.mysql.jdbc.Driver"  
        username="root"  
        password="nington"  
    />  
    <Resource 
        name="jdbc/mysql_c3p0" scope="Shareable"  
        type="com.mchange.v2.c3p0.ComboPooledDataSource"   
        factory="org.apache.naming.factory.BeanFactory"  
        jdbcUrl="jdbc:mysql://localhost:3306/armstrong" driverClass="com.mysql.jdbc.Driver"  
        user="root" password="nington" />
  </GlobalNamingResources>

context.xml

<Context>
    <WatchedResource>${catalina.base}/conf/web.xml</WatchedResource> 
    <ResourceLink global="jdbc/mysql_c3p0" name="jdbc/mysql" type="javax.sql.DataSource" />  
    <WatchedResource>WEB-INF/web.xml</WatchedResource>
</Context>

spring.xml

 <!--<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"-->
          <!--destroy-method="close">-->
        <!--<property name="driverClass" value="${app.db.driver}"/>-->
        <!--<property name="jdbcUrl" value="${app.db.url}"/>-->
        <!--<property name="user" value="${app.db.user}"/>-->
        <!--<property name="password" value="${app.db.password}"/>-->
        <!--<property name="maxPoolSize" value="${app.db.maxPoolSize}"/>-->
        <!--<property name="minPoolSize" value="10"/>-->
        <!--<property name="initialPoolSize" value="10"/>-->
        <!--<property name="maxIdleTime" value="20"/>-->
    <!--</bean>-->

    <jee:jndi-lookup id="dataSource" jndi-name="jdbc/mysql" />

不出问题的话,应该就可以了。当然tomcat还有很多其他配置方式,有兴趣可以查阅相关的资料。

超越数据源

当然,J2EE 中的资源并不局限于 JDBC 数据源。引用的类型有很多,其中包括资源引用(已经讨论过)、环境实体和 EJB 引用。特别是
EJB 引用,它暴露了 JNDI 在 J2EE 中的另外一项关键角色:查找其他应用程序组件。 试想一下这种情况:当一家公司从 Order
Ontology Processing Services(OOPS)购买了一个可部署的 EJB
组件来处理客户订单时,会发生什么。为了便于举例说明,我们把它叫做 ProcessOrders V1.0。ProcessOrders 1.0
有两部分:一组接口和支持类(home 和 remote 接口,以及支持的传输类);实际 EJB 组件自身。选择 OOPS
是因为它在这个领域的专业性。 该公司遵照 J2EE 规范,编写使用 EJB 引用的 Web 应用程序。公司的部署人员把
ProcessOrders 1.0 绑定到 JNDI 树中,将它用作 ejb/ProcessOrders/1.0,并解析 Web
应用程序的资源名称,以指向这个全局 JNDI 名称。目前为止,这些都是 EJB
组件非常普通的用法。但是,当我们考虑公司的开发周期与公司供应商之间的交互时,事情就变得复杂起来。在这里,JNDI 也能帮助我们。 我们假设
OOPS 发布了一个新版本,即 ProcessOrders
V1.1。这个新版本有一些新功能,公司内部的一个新应用程序需要这些新功能,而且很自然地扩展了 EJB 组件的业务接口。
在这里,公司有以下几个选择:可以更新所有应用程序来使用新版本,也可以编写自己的版本,或者使用 JNDI
的引用解析,允许每个应用程序在不影响其他应用程序的情况下使用自己的 EJB
组件版本。立刻更新所有应用程序对维护来说是一场噩梦,它要求对所有组件都进行完整的回归测试,这通常是一项艰巨的任务,而且如果发生任何功能测试失败的话,那么还要进行另一轮调试。
编写内部(in-house)组件常常是没有必要的重复工作。如果组件是由在这个业务领域内具有专业知识的公司编写的,那么给定的 IT
商店不可能像专业的组件供应商那样精通业务功能。 正如您可能已经猜到的那样,最好的解决方案是用 JNDI 解析。EJB 的 JNDI
引用非常类似于 JDBC 资源的引用。对于每个引用,部署人员都需要把新组件按特定的名称(比如说
ejb/ProcessOrders/1.1)绑定到全局树中,对于需要 EJB 组件的其他每个组件,还要为组件在部署描述符中解析 EJB
引用。依赖于 V1.0
以前的应用程序不需要进行任何修改,也不需要重新测试,这缩短了实现的时间、降低了成本并减少了复杂性。在服务趋于转换的环境中,这是一种很有效的方法。可以对应用程序架构中所得到的所有组件进行这类配置管理,从
EJB 组件到 JMS
队列和主题,再到简单配置字符串或其他对象,这可以降低随时间的推移服务变更所产生的维护成本,同时还可以简化部署,减少集成工作。

结束语

有一个古老的计算机科学笑话:每个编程问题都可以仅仅用一个抽象层(或间接的)来解决。在 J2EE 中,JNDI 是把 J2EE 应用程序合在一起的粘合剂,但还没有紧到无法让人很容易地把它们分开并重新装配。JNDI 提供的间接寻址允许跨企业交付可伸缩的、功能强大且很灵活的应用程序。这是 J2EE 的承诺,而且经过一些计划和预先考虑,这个承诺是完全可以实现的。实际上,它要比许多人想像的容易得多。

版权声明:欢迎访问个人博客网站 www.dubby.cn,和个人微信公众号ITBusTech

相关文章推荐

在Tomcat配置JNDI数据源的三种方式

在我过去工作的过程中,开发用服务器一般都是Tomcat 数据源的配置往往都是在applicationContext.xml中配置一个dataSource的bean 然后在部署时再修改JNDI配置 ...

在Tomcat上配置Proxool的DataSource(Jndi) --第2种方法

第一个方法是在容器,也就是Tomcat上做配置,但是,有时候会不适用,比如虚拟主机,它可能不允许你在机器上做配置,那样,就只能从自身的程序着手. 首先,写一个Proxool的配置文件.....放在 ...
  • big1980
  • big1980
  • 2011年03月24日 11:17
  • 904

在Tomcat上配置Proxool的DataSource(Jndi)

我使用的是Tomcat 6.0.14 + Proxool 0.9.1 Jndi在tomcat下做配置 先把需要的包复制进 %tomcat_path%/lib 需要的包为: proxool-0....
  • big1980
  • big1980
  • 2011年03月24日 11:10
  • 1511

JNDI 连接 Tomcat DataSource

JNDI(java Naming and Directory interface) 简单来说就是DataSource里面存了一定数量的JDBC Connection,Tomcat给我们创建了这个Da...

基于Tomcat6.0下的JNDI DataSource指引

Int    roduction JNDI Datasource configuration is covered extensively in theJNDI-Resource...

Web项目开发环境中运行在Tomcat时涉及到JNDI的Datasource的解决方法

通常在J2EE的开发中,需要用到在服务器上通过JNDI配置的Datasource,如最后的应用在Weblogic上运行,而在开发环境的本地机器中可能是Tomcat,这时候需要在Tomcat上配置一个D...
  • kkdelta
  • kkdelta
  • 2012年02月28日 14:39
  • 4090

Tomcat数据源(Tomcat DataSource JNDI Example )

Tomcat提供了三种利用JNDI方式配置数据源的形式: 1、应用程序中的context.xml,这也是最简单的一种方式,我们只需要在你自己的应用程序下的META-INF文件夹里建立一个contex...

TOMCAT JNDI配置

  • 2016年02月29日 15:58
  • 47KB
  • 下载

Tomcat中数据源(DataSource)连接池的配置使用

大概意思是:     使用数据源之后也同时使用了tomcat自带的连接池(DBCP):容器的连接池设置了一些准备公用的connection,程序用时拿走用,用完再送回池。这些连接由数据源统一管理维护...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:JNDI初探之tomcat的datasource配置
举报原因:
原因补充:

(最多只允许输入30个字)