JNDI – 什麼是 java:comp/env？

1. 概述

Java 命名和目錄介面 (JNDI) 是一個應用程式介面 (API)，它為基於 Java 的應用程式提供命名和目錄服務。我們可以使用這個介面來綁定對象/資源，尋找或查詢對象，並偵測同一對象的變更。

在本教程中，我們將專門研究在 JNDI 命名中使用「 java:comp/env 」標準前綴的背景。

簡單來說，命名服務是一個將名稱與物件關聯起來的接口，然後藉助名稱來尋找這些物件。因此，命名服務維護一組將名稱與物件對應的綁定。

JNDI API 使應用程式元件和用戶端能夠尋找分散式資源、服務和 EJB。

Context介面提供對命名環境的存取。使用此對象，我們可以將名稱綁定到對象、重新命名對象並列出綁定。讓我們看看如何獲取上下文：

JndiTemplate jndiTemplate = new JndiTemplate();
 context = (InitialContext) jndiTemplate.getContext();

一旦我們有了上下文，我們就可以綁定物件：

context.bind("java:comp/env/jdbc/datasource", ds);

然後，我們可以檢索上下文中存在的物件：

context.lookup("java:comp/env/jdbc/datasource");

如前面的範例所示，我們用標準前綴「 java:comp/env 」綁定名稱。在我們的例子中，它是“ java:comp/env/jdbc/datasource ”，而不僅僅是“ jdbc/datasource ”。這個前綴是強迫的嗎？我們能完全避免嗎？來！我們討論一下。

JNDI，顧名思義，是一種命名和目錄服務。因此， 目錄服務將名稱與物件相關聯，並且還允許此類物件具有屬性。因此，我們不僅可以透過名稱來尋找對象，還可以取得對象的屬性或根據對象的屬性來尋找對象。一個生動的例子是電話目錄服務，其中訂戶的姓名不僅映射到他的電話號碼，還映射到他的地址。

目錄通常依層次結構排列物件。在大多數情況下，目錄物件儲存在樹結構中。因此，第一個元素/節點可能包含群組對象，而這些對象可能包含特定對象。

例如，在「 java:comp/env 」中，「 comp 」元素是第一個節點，在下一個層級上，它包含「 env 」元素。從這裡，我們可以根據我們的約定儲存或存取資源。例如，「 jdbc/datasource 」共享一個資料來源物件。

讓我們分解一下之前的命名範例：「 java:comp/env/jdbc/datasource 」。

這裡，除了最後一個元素之外，所有其他父元素都是標準名稱，因此無法更改。

另外，根上下文是為策略的未來擴展而保留的。具體來說，這適用於命名不與元件本身相關但與其他類型的實體（例如使用者或部門）相關的資源。例如，未來的政策可能允許我們使用「 java:user/Anne”和「 java:org/finance 」等名稱來命名使用者和組織/部門。

如果我們想使用較短版本的 JNDI 查找，我們可以藉助子上下文來完成。這樣，我們就不需要提及命名的完整路徑（絕對路徑），而是子上下文的相對路徑。

我們可以從InitialContext物件派生一個子上下文，這樣我們就不必為檢索的每個資源重複「 java:comp/env 」：

Context subContext = (Context) context.lookup("java:comp/env");
 DataSource ds = (DataSource) subContext.lookup("jdbc/datasource");

正如我們在這裡看到的，我們建立了一個子上下文來保存「 java:comp/env 」中的值，然後使用這個子上下文（相對路徑）來尋找其中的特定命名。

在本文中，我們快速了解了什麼是 JNDI 及其用例。然後，我們了解如何將 JNDI 名稱綁定到上下文並尋找相同的名稱。

隨後，我們看到了標準前綴「 java:comp/env 」的拆分以及在 JNDI 命名中使用該前綴的原因。我們也注意到，未來的政策很可能會同時擴展根上下文「 comp 」和子上下文「 env 」。

與往常一樣，本文中使用的所有程式碼範例都可以在 GitHub 上取得。