关于Jboss/Tomcat/Jetty的JNDI定义123

      貌似有段时间没来这里忽悠了，今天抽空接着忽悠下这三个服务器配置JNDI时的一些异同点并提点自己的建议。

• Jboss 4
  

      Jboss中配置JNDI最常见的就是在配置数据源的时候，在server/default/deploy目录下方一个xxx-ds.xml文件，内容如下：

<?xml version="1.0" encoding="UTF-8"?> <datasources> 　　<local-tx-datasource> 　　　　　 <jndi-name>jdbc/DataSource</jndi-name> 　　　　　 <connection-url>jdbc:jtds:sqlserver://localhost:1433/fnx</connection-url> 　　　　　 <driver-class>net.sourceforge.jtds.jdbc.Driver</driver-class> 　　　　　 <user-name>sa</user-name> 　　　　　 <password>1234</password> 　　　　　<metadata> 　　　　　<type-mapping>MS SQLSERVER2000</type-mapping> 　　　　　</metadata> 　　　　 </local-tx-datasource> </datasources>  

这样我们启动服务器后，在web应用中就可以通过如下代码就可以直接访问到数据源：

Context ctx = new InitialContext(); Object o=ctx.lookup("java:jdbc/DataSource");

然而这里的java:jdbc/DataSource是一个全局资源名称，Jboss自动将资源加入全局资源，我们经常在应用中看到的java:comp/env/jdbc/DataSource 又是怎么回事？这其实是应用

的私有环境引用名，如果要使用这个引用名称，需要做两件事情(必须做)，1、在应用的WEB-INF目录下创建jboss-web.xml，并设置全局到局部引用名得映射

<jboss-web> <resource-ref> <res-ref-name>jdbc/DataSource</res-ref-name> <res-type>javax.sql.DataSource</res-type> <jndi-name>java:/jdbc/DataSource</jndi-name> </resource-ref> <context-root>/</context-root> </jboss-web>

2、在web.xml中设置

<web-app> <display-name>Archetype Created Web Application</display-name> <resource-ref> <description>dataSource</description> <res-ref-name>jdbc/DataSource</res-ref-name> <res-type>javax.sql.DataSource </res-type> <res-auth>Container</res-auth> </resource-ref> </web-app>

这样就可以在web应用中使用 java:comp/env/jdbc/DataSource 私有名了。

• Tomcat 6

 tomcat中配置JNDI有三个地方：

 1、在服务器的Server元素下配置全局的JNDI<GlobalNamingResources>

 2、在host元素的<DefaultContext>中配置，配置后对该host下所有的context应用都有效

 3、在context元素下配置，这里配置的只对该应用有效。

 

需要注意的是，第一种方式配置的全局JNDI，需要在context中使用<ResourceLink>元素转换成局部名才可以使用，功能跟jboss-web.xml中的转换类似。另外，tomcat 中配置的资源不需要在web.xml中进行声明，也可以通过java:comp/env形式进行访问，这一点跟Jboss/jetty有区别。

  上面三个地方可以配置的资源元素是Resource/Environment,ResourceParams是配合Resource使用，而ResourceLink是为了连接转换全局资源。

举个简单例子，在context元素下的配置：（其他的各位自己去看元素如何使用）

<Resource name="mybase" 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" />

这样就可以直接在web中使用 java:comp/env/mybase 来查询到资源了。不过还是建议在web.xml中声明一下。

• Jetty 7
  

Jetty的JNDI配置也分3个范围

 1、基于JVM全局的，也就是同一个JVM下不同的Server都可以访问

 2、基于Server的，只能在该server下可以访问

 3、基于应用context上下文的，只能在该context下能够访问

配置方式见我上面一篇《JNDI和在JETTY中的运用》

不过这里要注意的是，采用java:comp/env方式访问时，一定要在web.xml中声明资源(除了配置的EnvEntry元素除外，他自动会加入到私有资源)，否则你是拿不到资源的。

 

 

• 总结

可以看到，每个服务器都有他自己的JNDI配置方式和全局访问方式，如果我们直接采用全局访问方式，第一对于一些只对某些应用有关的资源配置可能访问不到，例如JETTY，第二每个

应用服务器的全局访问方式可能不太一致。因此一般建议在应用程序中采用私有方式(java:comp/env)访问资源，并且无论如何都在web.xml中进行申明。这是一个良好的习惯。

 

 

  另外：说到私有环境ENC(java:comp/env),他是如何变成私有的？其实私有是对每个应用上下文来说的，一般每个应用上下文都会用自己的classloader来加载应用，因此利用classloader便可以完成。具体方式是： 用每个应用自己的上下文 cloassloader 来初始化一个 JNDI context . 并以 classoader 为 key 保存起来，以后应用检索时需要使用的应用自己上下文的 classloader来查找这个JNDI 资源即可 ，由于其他应用使用不同的classloader实例，也就不能相互共享了，这就是每个应用私有了。另外如果资源命名时采用： java:resourceName, 或者 prefix:resourceName 的方式，虽然我们可以通过 java:resourceName, 或者 prefix:resourceName 的方式直接访问，但也注定了这不是私有资源，所有应用都可以访问，需要放到 ENC 下才是私有资源。绑定在 ENC 下访问： java:comp/env/prefix:resourceName