私は完全なアプリケーションサーバーのバックグラウンドから来ており、Jettyなどの軽量の組み込みサーバーでアプリを実行することを検討しています。
私は常にJNDIを使用して、データベース接続などの接続プールを検索してきましたが、それが軽量の場合に最適なアプローチであるかどうか疑問に思っています。JNDIを使用しても何のメリットも得られないようですが、さまざまなコンテナーの構成方法にばらつきがあり、セットアップがさらに複雑になります。
私が見ることができる代替案は、接続プールの実装をアプリに埋め込むことです。私がSpringを使用しているので、このアプローチは必要な構成が少し少なく、必要な構成はすべて1か所にあり（必要に応じて他の場所から接続の詳細などの単純な名前と値のプロパティを検索する機能を備えています）、関係なく機能するようです。コンテキスト（dev / test / live）とデプロイするコンテナーについて説明します。
ここで何かが足りませんか？アプリケーションにアプリケーションサーバーを埋め込む場合でも、JNDIを使用する必要がありますか？もしそうなら、なぜですか？
それは完全にあなたの状況に依存します。
JNDI（私にとって）は、デプロイするものとデプロイする場所との間の分離を実現するためのメカニズムです。デプロイするときに、特定のリソースが使用可能であり、X、Y、およびZのラベルが付けられると想定します。JNDIは、これらのリソースを基本的に均一な方法で提供するための単純な（ちょっとした）メカニズムです。サポートされているデータベースが複数ある可能性があり、すべてのコードをデータソースに対して記述したい場合は、そのデータソースをどこかに構成する必要があり、jndiはそれを実行する場所を提供します。jndiを簡単に設定できるようなツールを使用している場合は、それを使用してください。
埋め込まれた状況では、状況は実際には変わりません。それでも、どこかで設定する必要があります。ただし、組み込みアプリケーションの過程で、jndi方程式の両側を記述していることに気付いた場合は、この追加の抽象化レイヤーが必要かどうかを自問してください。
jndiを使用しているのは、他のすべての人が行っていることですが、実際にはpostgresのみを使用し、そのデータベースドライバーが必要な場合は、アプリケーションの複雑さがさらに増すポイントは何ですか。スプリングが本当に好きな場合は、スプリングを使用すると、必要なビットとピースを簡単に構成し、必要な場所に挿入できます...jndiは使用しないでください。
fwiw、jndiはもう必要ないようですね:)