我来自完整的应用程序服务器背景，并考虑在轻量级嵌入式服务器（如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_嵌入并完成，但并不意味着所有使用的库都知道这一点。你仍然需要将它们连接在一起。 –
考虑寻找未来项目的依赖注入。 –