在描述JNDI,例如获得数据源时,JNDI地址 有两种写法,例如同是 jdbc/testDS 数据源:
A: java:comp/env/jdbc/testDS
B: jdbc/testDS
这两种写法,配置的方式也不尽相同,第一种方法应该算是一种利于程序移植或迁移的方法,它的实现与“映射”的概念相 同,而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子上下文中声明
可以通过下面的结构示意来发现这两种描述的不同之处:
A: java:comp/env/jdbc/testDS(虚地址) ------> 映射描述符 ------> jdbc/testDS (实际的地址)
B: jdbc/testDS (实际的地址)
从这种结构上来看,A的确是便于移植的。
再来看一个例子:
假如你需要获取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>
Tomcat5.5h server.xml中加入:
<Context
docBase="D:/workspace/Hello/WebContent"
path="/Hello"
reloadable="true">
<Resource
name="jdbc/DBPool"
type="javax.sql.DataSource"
maxActive="100"
maxIdle="10"
maxWait="3000"
driverClassName="com.microsoft.sqlserver.jdbc.SQLServerDriver"
url="jdbc:sqlserver://192.168.1.37:1433;DatabaseName=xxx;user=sa;password=sa123"/>
</Context>
实际服务器中的JNDI名字是OraDataSource,逻辑名jdbc/DBPool只是用来和它作映射的,这样做的好处是为了提高可移植性,移植的 时候只需要把配置文件改一下就可以,而应用程序可不用改动。
java:comp/env是标准的J2EE环境查找规则使用这种方式必须做一次环境名到JNDI名的映射这种隔离使得在写程序时不必关注真正的 JNDI名字其实说白了跟把JNDI名放到配置文件里是一样的用法,如把java:comp/env/my/datasource映射到 my.ora.dataource
补充一下不加的时候是全局的JNDI名,这样将造成应用间EJB的耦合太高,不建议使用
注:
java:comp/env/ 前面是固定的
java:comp/env是标准的J2EE环境查找规则
comp是company的缩写
env是environment的缩写
使用这种方式必须做一次环境名到JNDI名的映射
这种隔离使得在写程序时不必关注真正的JNDI名字
其实说白了跟把JNDI名放到配置文件里是一样的
其他扩展:
J2EE 1.3 ,资源的管理绑定一个资源,但是使用时应该先配置资源引用 。
你在 web.xml 中或者 ejb-jar.xml 上配置对 EJB 或者 DataSource 的引用才能使用相应的资源。
不管是资源的配置还是资源引用的配置都可以在布署的阶段来修改的, 但是程序可以不用改,你只要让引用不变就行了,因为你自己容器中将要放多少东西你写代码时就知道(就是一个项目要用的东西),但是你的服务器中将来要放多 少资源你写代码时是不知道的,因为资源是在整个服务器,很容易在将来的某个时候可能多得不可管理。
在 web.xml 和 ejb-jar.xml 都可以有个 mycompay/abc 这个资源引用,名字相同没关系,因为它们在不同的容器中,只要同一个容器中唯一就行了,资源引用与实际资源的JNDI 相同也没关系。
现在的应用服务器都支持 J2EE 1.3,都会有个把 资源引用对应到一个实际的资源的这么一个配置文件。 像 IBM WebSphere 在 web 项目中 /WEB-INF/ibm-web-bnd.xml 就是用来将一个资源引用绑定到实际的 JNDI 资源上去的, 而EJB 项目中是 ibm-ejb-jar-bnd.xml 。
我用 &Web&Sphere &Application &Developer 开发的时候, 在 web.xml 中添加一个资源引用,比如对数据源的引用 ,WSAD 会自动到 ibm-web-bnd.xml中添加一个相应的绑定条目,如果我在 ejb-jar.xml 中添加一个 Local Ejb Ref , WSAD 也会自动到 ibm-ejb-jar-bnd.xml 中添加一个相应的条目。
假如你写了一个EJB,获取datasource如:dataSource = (DataSource) ctx.lookup("java:comp/env/jdbc/DBPool");
那么在配置文件中进行资源映射时,在ejb-jar.xml中,
<resource-ref>
<res-ref-name>jdbc/DBPool</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
在weblogic-ejb-jar.xml中,
<reference-descriptor>
<resource-description>
<res-ref-name>jdbc/DBPool</res-ref-name>
<jndi-name>OraDataSource</jndi-name>
</resource-description>
</reference-descriptor>
//转者注:如果是在jboss则在jboss.xml中做如下修改
<resource-managers>
<resource-manager>
<res-name>jdbc/DBPool</res-name>
<res-jndi-name>OraDataSource</res-jndi-name>
</resource-manager>
</resource-managers>
实际服务器中的JNDI名字是OraDataSource,逻辑名jdbc/DBPool只是用来和它作映射的,这样做的好处是为了提高可移植性,移植的 时候只需要把配置文件改一下就可以,而应用程序可不用改动。
假如你写了一个一般的应用程序,想直接通过JNDI来获取数据源,那么直接lookup(“mytest”)就可以了(假如服务器上的JNDI为 mytest),用第一种写法反而会报错的。
A: java:comp/env/jdbc/testDS
B: jdbc/testDS
这两种写法,配置的方式也不尽相同,第一种方法应该算是一种利于程序移植或迁移的方法,它的实现与“映射”的概念相 同,而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子上下文中声明
可以通过下面的结构示意来发现这两种描述的不同之处:
A: java:comp/env/jdbc/testDS(虚地址) ------> 映射描述符 ------> jdbc/testDS (实际的地址)
B: jdbc/testDS (实际的地址)
从这种结构上来看,A的确是便于移植的。
再来看一个例子:
假如你需要获取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>
Tomcat5.5h server.xml中加入:
<Context
docBase="D:/workspace/Hello/WebContent"
path="/Hello"
reloadable="true">
<Resource
name="jdbc/DBPool"
type="javax.sql.DataSource"
maxActive="100"
maxIdle="10"
maxWait="3000"
driverClassName="com.microsoft.sqlserver.jdbc.SQLServerDriver"
url="jdbc:sqlserver://192.168.1.37:1433;DatabaseName=xxx;user=sa;password=sa123"/>
</Context>
实际服务器中的JNDI名字是OraDataSource,逻辑名jdbc/DBPool只是用来和它作映射的,这样做的好处是为了提高可移植性,移植的 时候只需要把配置文件改一下就可以,而应用程序可不用改动。
java:comp/env是标准的J2EE环境查找规则使用这种方式必须做一次环境名到JNDI名的映射这种隔离使得在写程序时不必关注真正的 JNDI名字其实说白了跟把JNDI名放到配置文件里是一样的用法,如把java:comp/env/my/datasource映射到 my.ora.dataource
补充一下不加的时候是全局的JNDI名,这样将造成应用间EJB的耦合太高,不建议使用
注:
java:comp/env/ 前面是固定的
java:comp/env是标准的J2EE环境查找规则
comp是company的缩写
env是environment的缩写
使用这种方式必须做一次环境名到JNDI名的映射
这种隔离使得在写程序时不必关注真正的JNDI名字
其实说白了跟把JNDI名放到配置文件里是一样的
其他扩展:
J2EE 1.3 ,资源的管理绑定一个资源,但是使用时应该先配置资源引用 。
你在 web.xml 中或者 ejb-jar.xml 上配置对 EJB 或者 DataSource 的引用才能使用相应的资源。
不管是资源的配置还是资源引用的配置都可以在布署的阶段来修改的, 但是程序可以不用改,你只要让引用不变就行了,因为你自己容器中将要放多少东西你写代码时就知道(就是一个项目要用的东西),但是你的服务器中将来要放多 少资源你写代码时是不知道的,因为资源是在整个服务器,很容易在将来的某个时候可能多得不可管理。
在 web.xml 和 ejb-jar.xml 都可以有个 mycompay/abc 这个资源引用,名字相同没关系,因为它们在不同的容器中,只要同一个容器中唯一就行了,资源引用与实际资源的JNDI 相同也没关系。
现在的应用服务器都支持 J2EE 1.3,都会有个把 资源引用对应到一个实际的资源的这么一个配置文件。 像 IBM WebSphere 在 web 项目中 /WEB-INF/ibm-web-bnd.xml 就是用来将一个资源引用绑定到实际的 JNDI 资源上去的, 而EJB 项目中是 ibm-ejb-jar-bnd.xml 。
我用 &Web&Sphere &Application &Developer 开发的时候, 在 web.xml 中添加一个资源引用,比如对数据源的引用 ,WSAD 会自动到 ibm-web-bnd.xml中添加一个相应的绑定条目,如果我在 ejb-jar.xml 中添加一个 Local Ejb Ref , WSAD 也会自动到 ibm-ejb-jar-bnd.xml 中添加一个相应的条目。
假如你写了一个EJB,获取datasource如:dataSource = (DataSource) ctx.lookup("java:comp/env/jdbc/DBPool");
那么在配置文件中进行资源映射时,在ejb-jar.xml中,
<resource-ref>
<res-ref-name>jdbc/DBPool</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
在weblogic-ejb-jar.xml中,
<reference-descriptor>
<resource-description>
<res-ref-name>jdbc/DBPool</res-ref-name>
<jndi-name>OraDataSource</jndi-name>
</resource-description>
</reference-descriptor>
//转者注:如果是在jboss则在jboss.xml中做如下修改
<resource-managers>
<resource-manager>
<res-name>jdbc/DBPool</res-name>
<res-jndi-name>OraDataSource</res-jndi-name>
</resource-manager>
</resource-managers>
实际服务器中的JNDI名字是OraDataSource,逻辑名jdbc/DBPool只是用来和它作映射的,这样做的好处是为了提高可移植性,移植的 时候只需要把配置文件改一下就可以,而应用程序可不用改动。
假如你写了一个一般的应用程序,想直接通过JNDI来获取数据源,那么直接lookup(“mytest”)就可以了(假如服务器上的JNDI为 mytest),用第一种写法反而会报错的。