Java ServiceLocator是否应该查找数据源的jndi名称？

我有一个J2EEWebApp，用于上传一个文件，然后由数据库过程进行处理。因为我们不希望webapp必须等待数据库过程完成，所以它在另一个线程中执行

在单独线程中运行的进程需要获取并关闭自己的连接。webapps通常使用ServiceLocator查找数据源jndi名称，ServiceLocator反过来从应用程序上下文中查找数据源jndi名称（jndi名称的查找键定义为类常量），但是对于使用ServiceLocator查找jndi名称的单独线程，查找jndi名称失败。为了解决这个问题，我们使用jndi名称作为类常量，以便线程可以直接查找数据源

这意味着数据源的jndi名称现在已为应用程序固定，我们不能再通过修改web.xml将同一应用程序部署在同一容器中，而是使用不同的数据源

---

围绕这一点的行业最佳实践是什么？jndi名称应该是可配置的，还是可以为应用程序修复它？是否有人实现了一个可配置的数据源jndi名称解决方案，该解决方案在webapp中和容器中的其他线程都可用？

您可以将jndi名称或数据源作为thread类的构造函数或方法参数传入。

是的-我感觉到了您的痛苦

我确实认为，尝试通过web.xml配置jndi是一个非常好的主意。我处理这个问题的方法是缓存数据源引用。现在，在webapp启动时，引用的数据源在线程可用时被获取，然后传递给或提供给任何其他需要它的对象。

关于最佳实践，（由Kirk Pepperdine合著）是我找到的最好的文章之一。它清楚地解释了Sun关于开发、打包、部署以及JNDI如何融入其中的“愿景”

简短的版本是Sun和application Server提供程序提供了一种定义和命名全局资源（java:DefaultDS）以及将本地资源引用名称（jdbc/mydatasource）绑定到命名资源的方法

这解决了应用程序（由J2EE组件组成）的可移植性问题。但是本地资源引用名称是特定于组件的，因此它不能解决您的问题（即多次部署同一组件，但使用不同的本地资源引用名称）

换句话说，Sun的愿景并没有针对您的特定用例（尽管我认为这是一个有效的用例）。对于Sun模型，您应该在构建/打包时解决这个问题（即创建和组装组件的两个版本，每个版本使用特定的本地资源引用名称）

您描述的编程方法（从存储在JDNI/properties/where中的键中查找值）是一种变通方法