使用JNDI的NameNotFoundException

我寫的迴歸測試的內部庫（其中創作者looong了），我試圖驗證環境的失敗。只有在jndi名稱爲「複雜」時，幾個測試纔會與NameNotFoundException一起失敗。使用JNDI的NameNotFoundException

這是一個獨立的應用程序，並沒有運行任何Web容器。該應用程序使用首選項文件，並且不涉及LDAP。該環境是Java v1.4，並且該應用程序安裝了本地所有必需的庫。（lib目錄與jndi.jar，jms.jar等）。很簡單，對吧？

由於庫的複雜性，以及如何futzes周圍有很多的對象，我有一個簡單的測試，然後斜升複雜每一塊作爲一個單獨的測試增加。

設置：文件：C：\數據\蝕\工作空間\ APP \ testfiles \ JNDI \ JMS \標籤\ .bindings
在文件中，有以下條目：QReply/FactoryName = com.ibm.mq.jms .MQQueueFactory

單元測試類別：「簡單」的測試有

Hashtable ht = new Hashtable(); 
ht.put(Context.PROVIDER_URL, 
    "file:/data/eclipse/workspace/APP/testFiles/jndi/jms/label/"); 
ht.put(Context.INITIAL_CONTEXT_FACTORY, 
    "com.sun.jndi.fscontext.RefFSContextFactory"); 
ht.put(Context.SECURITY_AUTHENTICATION, "none"); 
Context ctx; 
try { 
    ctx = new InitialContext(ht); 
    String jndiName = "QReply"; 
    logger.debug("testFindRemoteObject_Simple", 
     "Invoking InitialContext.lookup(\"" + jndiName + "\")"); 
    Object remoteObject = ctx.lookup(jndiName); 
    assertTrue(remoteObject != null); 
} catch (NamingException e) { 
    e.printStackTrace(); 
    fail(e.getMessage()); 
}

此通過。因爲我在圖書館遇到了很多麻煩，所以我創建了另一個與傳入的實際數據相匹配的測試; Provider URL縮短，jndi名稱選擇「路徑」。

「實際」的數據單元測試：

final Hashtable ht = new Hashtable(); 
ht.put(Context.PROVIDER_URL, 
    "file:/data/eclipse/workspace/APP/testFiles/jndi/"); 
ht.put(Context.INITIAL_CONTEXT_FACTORY, 
    "com.sun.jndi.fscontext.RefFSContextFactory"); 
ht.put(Context.SECURITY_AUTHENTICATION, "none"); 
Context ctx; 
try { 
    ctx = new InitialContext(ht); 
    String jndiName = "jms/label/QReply"; 
    logger.debug("testFindRemoteObject_Actual", 
      "Invoking InitialContext.lookup(\"" + jndiName + "\")"); 
    Object remoteObject = ctx.lookup(jndiName); 
    assertTrue(remoteObject != null); 
} catch (NamingException e) { 
    e.printStackTrace(); 
    fail(e.getMessage()); 
}

哪個失敗

javax.naming.NameNotFoundException: jms/label/QReply 
at com.sun.jndi.fscontext.RefFSContext.getObjectFromBindings(
     RefFSContext.java:400) 
at com.sun.jndi.fscontext.RefFSContext.lookupObject(RefFSContext.java:327) 
at com.sun.jndi.fscontext.RefFSContext.lookup(RefFSContext.java:146) 
at com.sun.jndi.fscontext.FSContext.lookup(FSContext.java:127) 
at javax.naming.InitialContext.lookup(InitialContext.java:347) 
at com.advo.tests.services.UnitTestServiceLocator.testFindRemoteObject_Actual(
      UnitTestServiceLocator.java:85)

其中UnitTestServiceLocator.java:85是ctx.lookup（jndiname）的線;

爲什麼簡單測試通過但更復雜的測試失敗？兩者都使用指向lib目錄的類路徑，該目錄中填充了jms和mq jar（以及其他內容）。

的複雜測試匹配什麼圖書館將填補，但使用魔法作爲值傳遞。庫代碼具有「少數」多行，從首選項文件中提取魔術值。我錯過了什麼？庫代碼將在服務器上工作，但在我的筆記本電腦上失敗（開發時）。

我甚至創造了另一個JNDI路徑 - 以防萬一第一次測試是打亂第二。仍然失敗。

因爲我沒有任何慾望（或權限更改庫代碼），調用的InitialContext（X）;就是這樣，因爲這是圖書館做它的方式。我看過其他的例子，沒有任何通過InitialContext傳遞，我很困惑爲什麼這樣更好。

更新：我在linux java1.5上創建了一個jndi_test項目，併成功運行失敗的測試。採取相同的來源並將其移至Windows環境 - 測試失敗。由於Linux上沒有C盤，但數據文件相同，因此對類路徑進行了一些更改。（嗯分隔符的問題？）

我還發現，我有與該庫的問題，如果我要在1.5上運行它，但是這是一個次要問題。

來源

2009-02-18 jim

爲了讓我的生活更加悲慘，圖書館有4層間接的，它指向指向指向實際的服務隊列中的JNDI文件的服務定位器文件中的首選項文件。 – jim 2009-02-18 19:59:05

我認爲你會混淆JNDI名稱。

「QReply」是JNDI名稱。你甚至這樣說：

在文件中有這樣的條目：QReply/FactoryName = com.ibm.mq.jms.MQQueueFactory

如果條目是：「JMS /標籤/ QReply」，然後你的第二個測試會奏效。

來源

2009-02-18 21:38:33

不知道這是問題。庫代碼與高級測試與「拆分」網址完全相同。它不會對createSubContext調用做任何事情，這是有道理的。 – jim 2009-02-18 22:08:24

使用JNDI的NameNotFoundException

回答

相關問題