在描述JNDI,例如得到数据源时,JNDI地址有两种写法,例如同是 jdbc/testDS 数据源:
A: java:comp/env/jdbc/testDS
B: jdbc/testDSjava
这两种写法,配置的方式也不尽相同,第一种方法应该算是一种利于程序移植或迁移的方法,它的实现与“映射”的概念相同,而B方法,则是一个硬引用。
java:comp/env 是环境命名上下文(environment naming context(ENC)),是在EJB规范1.1之后引入的,引入这个是为了解决原来JNDI查找所引发的冲突问题,也是为了提升EJB或者J2EE应用的移植性。
在J2EE中的引用经常使用的有:
JDBC 数据源引用在java:comp/env/jdbc 子上下文中声明
JMS 链接工厂在java:comp/env/jms 子上下文中声明
JavaMail 链接工厂在java:comp/env/mail 子上下文中声明
URL 链接工厂在 java:comp/env/url子上下文中声明web
能够经过下面的结构示意来发现这两种描述的不一样之处:
A: java:comp/env/jdbc/testDS(虚地址) ------> 映射描述符 ------> jdbc/testDS (实际的地址)
B: jdbc/testDS (实际的地址)
从这种结构上来看,A的确是便于移植的。sql
再来看一个例子:
假如你须要获取datasource,例如:dataSource = (DataSource) ctx.lookup("java:comp/env/jdbc/testDS");
那么在配置文件中进行资源映射时,在web.xml中,
<resource-ref>
<res-ref-name>jdbc/testDS</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
在相应的资源配置xml中(不一样的应用服务器均不一样,WSAD中,能够进行可视化的设置),
<reference-descriptor>
<resource-description>
<res-ref-name>jdbc/DBPool</res-ref-name>
<jndi-name>OraDataSource</jndi-name>
</resource-description>
</reference-descriptor>
实际服务器中的JNDI名字是OraDataSource,逻辑名jdbc/DBPool只是用来和它做映射的,这样作的好处是为了提升可移植性,移植的时候只须要把配置文件改一下就能够,而应用程序可不用改动。服务器
假如你写了一个通常的应用程序,想直接经过JNDI来获取数据源,那么直接lookup(“mytest”)就能够了(假如服务器上的JNDI为mytest),用第一种写法反而会报错的。url