我想知道人们如何跨 Tomcat 应用程序服务器的多个实例管理维护 JNDI 资源。让我们以我的数据库 JNDI 资源为例。它在我的/conf/context.xml 文件中声明,并从我的应用程序 web.xml 文件中引用。
JNDI 资源必须在我的开发箱、暂存箱和生产箱上独立定义。如果我想设置开发人员/暂存/生产箱的新实例怎么办?这意味着我必须为我提出的每个新实例在 context.xml 中重新创建资源名称?从设置的角度来看,这里可能存在一些人为错误,可能会导致应用服务器开始指向错误的数据库。
我发现这既麻烦又令人困惑,因为我在项目中增加了开发人员的数量,并最终增加了我可能使用的生产服务器的数量。
您是将其作为设置的一部分还是创建一个设置脚本来在您每次重新安装 tomcat 并设置一个盒子时为您处理这个问题?或者是否有其他一些间接级别可以使这更容易?
最佳答案
我假设对于给定的资源,您在每个环境中使用相同的 JNDI 名称。否则,您必须编辑代码以指向新资源 (JNDI) 名称。
第一次设置环境几乎不可能提前测试。没有办法验证某些字符串(如生产数据库连接字符串)在您实际必须使用它之前没有被滥用。这是环境配置的本质。话虽如此,如果您想减少出错的可能性,首先您需要确保为每个资源指定一个名称,无论它托管在哪个环境中都可以使用该名称。在指向 jndi:/jdbc/myproject/resources/dbConnectionString 的属性文件中创建一个 dbConnectionString 资源名称,并确保所有环境都声明相同的资源。下面是我们如何将代码与这些类型的环境依赖性隔离开来。话虽这么说,您将始终必须手动验证特定服务器的配置是否正在为已定义的资源使用适当的值。
注意:永远不要创建诸如“dbProdConnectionString”、“dbQAConnectionString”、“dbDevConnectionString”之类的资源名称。您将无法达到尝试消除手动干预的目的,因为您添加了一个间接步骤,需要更改代码(将代码指向正确的资源名称)和构建(将更改打包到您的 .war 文件中) 在环境之间移动时。
我们所做的是为特定于环境的属性创建一个文件夹结构。在该文件夹下,我们为针对部署的每个特定环境创建了文件夹,包括本地开发。它看起来像这样:
Project
\
-Properties
\
-Local (your PC)
-Dev (shared dev server)
-Test (pre-production)
-Prod (Production)
在每个文件夹中,我们放置了属性/配置文件的平行副本,并将不同的配置仅放在相应文件夹中的文件中。秘诀在于控制部署环境的类路径。我们在每台服务器上定义了一个 PROPERTIES 类路径条目。在 Prod 上,它将设置为“$ProjectDir/Properties/Prod”,而在 Test 上,相同的变量将设置为“$ProjectDir/Properties/Test”。
这样我们就可以预先配置 dev/test/prod 数据库的数据库连接字符串,而不必在每次我们想要为不同的环境构建时 check out /在属性文件中。
这也意味着我们可以将完全相同的 .war/.ear 文件部署到测试和生产环境,而无需重新构建。我们通过在每个环境中使用相同的 JNDI 名称但使用特定于该环境的值以类似的方式处理任何未在属性文件中声明的属性。
关于deployment - 跨多个 Tomcat 实例维护 JNDI,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1127338/