我之前在维护多环境部署的Java EE项目时，也遇到过这个头疼的问题——新版本的Payara/GlassFish对persistence-unit的数据源验证变严格了，不像旧版本那样能容忍未配置的连接池。下面几个方法亲测有效，你可以根据自己的场景选择：

1. 关闭部署时的数据源验证（快速 workaround） #

Payara/GlassFish提供了参数可以跳过所有persistence-unit的数据源存在性检查，适合快速测试或者临时部署场景：

单次部署时生效 #

使用asadmin部署命令时添加verify-datasource=false属性：

asadmin deploy --property verify-datasource=false your-application.war

全局生效（服务器级配置） #

如果需要所有部署都跳过验证，可以修改服务器的domain.xml，在server-config的java-config中添加JVM参数：

<config name="server-config">
  <java-config>
    <jvm-options>-Dpayara.persistence.verify-datasource=false</jvm-options>
  </java-config>
</config>

修改后重启服务器即可生效。这个方法的缺点是会关闭所有应用的数据源验证，可能隐藏真正的配置错误，不建议生产环境长期使用。

2. 按环境拆分Persistence配置（生产环境推荐） #

最规范的做法是根据不同服务器环境，打包只包含对应persistence-unit的部署包。比如用Maven/Gradle的环境profile来实现：

• 在项目资源目录下创建多个persistence.xml模板，比如persistence-dev.xml、persistence-prod.xml，每个模板只包含对应环境需要的persistence-unit。
• 在构建工具的profile中配置，打包时将对应环境的模板复制为persistence.xml，替换默认文件。

这样每个环境的部署包只有需要的PU，从根源上避免了未配置数据源的PU存在，也符合“最小权限”的部署原则，是生产环境的首选方案。

3. 为未使用的PU配置虚拟数据源（临时 hack） #

如果不想修改构建流程或者服务器配置，可以在目标服务器上创建一个虚拟的连接池，名称对应未使用的PU的数据源名称。这个连接池不需要实际的数据库连接，只要能通过服务器的资源验证即可。

比如在Payara管理控制台中创建一个类型为javax.sql.DataSource的连接池，不需要配置数据库URL、用户名密码等，只要保证名称和PU中指定的jta-data-source或non-jta-data-source一致。部署时服务器会检测到这个连接池存在，就不会抛出NameNotFoundException了。

这个方法比较取巧，适合临时应急，但长期来看会增加服务器上的无用资源，不推荐作为长期解决方案。

内容的提问来源于stack exchange，提问作者Rafael Alcaide