Name xxx is not bound in this Context 總結

查詢了JNDI的相關資料和帖子以後得出結論,原來在使用有資源引用的J2EE程序時,context lookup的時候要加上環境上下文
即加上java:comp/env/

例如:

datasource = (DataSource) new InitialContext().lookup("java:comp/env/myDB");

這樣的內容.但彷佛有時候須要加,有時候又不須要.下邊收集其它人的總結以作參考備忘.

參考A:

通常狀況下咱們本身開發的ejb,和直接引用的jdbc,jms,java   mail是不用加java:comp/env/的
當咱們的ejb裏有其它的ejb引用時,或者有其它的資源引用時,訪問這些被引用的ejb和資源時
須要加上java:comp/env/!

參考B:

在描述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中,
那麼在配置文件中進行資源映射時，在web.xml中,
那麼在配置文件中進行資源映射時，在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），用第一種寫法反而會報錯的。