我來自完整的應用程序服務器背景，並考慮在輕量級嵌入式服務器（如Jetty）上運行應用程序。嵌入應用程序服務器時，JNDI還是不JNDI？
我一直使用JNDI來查找連接池來查找數據庫連接等事情，但我想知道這是否是輕量級案例的最佳方法。看起來，如果我使用JNDI，我沒有得到任何好處，但是我確實在不同容器的配置方式以及設置的複雜性方面存在差異。
我可以看到的另一種方法是在我的應用程序中嵌入連接池實現。在我使用Spring的時候，這種方法只需要少一點配置，需要的配置都集中在一個地方（如果需要，可以查找簡單的名稱 - 值屬性，例如來自其他地方的連接詳細信息），並且似乎無論如何工作上下文（dev/test/live）和我部署的容器。
我在這裏錯過了什麼嗎？如果我在應用程序中嵌入應用程序服務器，我還應該使用JNDI嗎？如果是這樣，爲什麼？
這完全取決於你的情況。
JNDI（對我而言）是一種實現部署和部署的位置之間的解耦的機制。因此，當您部署時，您假定某些資源將可用，並且它們將被標記爲X，Y和Z. JNDI是以基本一致的方式提供這些資源的簡單（有點）機制。如果你有可能有多個不同的支持數據庫，並且你想把所有的代碼寫入一些數據源......你需要配置的數據源和jndi給出了一些地方去做。如果你使用某種工具來設置jndi，那麼很棒，使用它。
在嵌入式情況下情況確實沒有改變，事情仍然需要設置在某個地方。但是，在嵌入式應用程序的過程中，您會發現自己寫了jndi方程的兩個方面，然後問自己是否需要這個額外的抽象層。
如果你只是使用JNDI，因爲這是任何其他人一樣，但你只能使用Postgres的真的，你只需要一個數據庫驅動程序......那麼什麼是複雜的爲您的應用額外的層的點。如果你真的喜歡春天和春天給你一個更簡單的方式來配置你需要的零件和注入它，你需要它注入...不要使用jndi。
fwiw，它聽起來像你不需要jndi了:)
把它寫成「寫入JNDI方程的兩邊」的好方法。 – Brabster
儘管_application_嵌入並完成，但並不意味着所有使用的庫都知道這一點。你仍然需要將它們連接在一起。 –
考慮尋找未來項目的依賴注入。 –