关于@DataSourceDefinition注解的生产环境使用疑问——明文密码属性与十二要素冲突及替代方案咨询

Great question—this is a super common pain point when balancing development convenience with production security and best practices like the Twelve-Factor App methodology. Let’s break this down step by step:

First, Confirm the Spec’s Intent #

You’re right to follow the Jakarta EE spec guidance: the password element in @DataSourceDefinition is explicitly meant for development-only convenience. Hardcoding production credentials here is a huge security risk, so we need alternatives for non-local environments.

Practical Solutions for Production & Non-Local Use #

Here are actionable approaches that avoid hardcoded passwords while keeping the annotation’s utility for development:

1. Conditional Loading with Profiles #

Use environment-specific profiles to enable @DataSourceDefinition only in local/dev environments, and switch to production-grade configuration elsewhere.

For example, with Jakarta EE’s @Profile (or container-specific equivalents like WildFly’s @Environment):

// Only active in development environments
@Profile("dev")
@DataSourceDefinition(
    name = "java:app/MyAppDS",
    className = "com.mysql.cj.jdbc.MysqlDataSource",
    url = "jdbc:mysql://localhost:3306/my_dev_db",
    user = "dev_user",
    password = "dev_pass" // Safe for local use only
)
public class DevDataSourceConfig {}

In production, replace this with a CDI producer that pulls credentials from externalized sources (environment variables, system properties, or a secure config service):

@ApplicationScoped
@Profile("prod")
public class ProdDataSourceProducer {
    @Produces
    @Resource(name = "java:app/MyAppDS")
    public DataSource createProductionDataSource() {
        MysqlDataSource ds = new MysqlDataSource();
        ds.setUrl(System.getenv("DB_URL"));
        ds.setUser(System.getenv("DB_USER"));
        ds.setPassword(System.getenv("DB_PASSWORD"));
        // Add additional production config (connection pooling, etc.)
        ds.setMaxPoolSize(20);
        return ds;
    }
}

This way, you keep the annotation’s speed for local development, while adhering to Twelve-Factor’s config externalization (principle III) and avoiding hardcoded secrets.

2. Container-Supported Secret Resolution #

Many Jakarta EE containers (like WildFly, TomEE, or Quarkus) extend the spec to support resolving secrets in annotations without hardcoding:

• WildFly: Use its Password Vault to encrypt credentials, then reference the vault alias in @DataSourceDefinition’s password field. The server automatically decrypts it at runtime.
• Quarkus: Natively supports microprofile config expressions in the annotation. You can use placeholders that pull from environment variables or application.properties:

  @DataSourceDefinition(
      name = "java:app/MyAppDS",
      className = "com.mysql.cj.jdbc.MysqlDataSource",
      url = "${db.url}",
      user = "${db.user}",
      password = "${db.password}"
  )
  

  This works in both dev and production—just set the corresponding environment variables or config values, aligning with Twelve-Factor’s environment parity (principle X).

3. Build-Time Placeholder Replacement #

If your container doesn’t support runtime expression resolution, you can use build tools like Maven or Gradle to replace placeholder values in the annotation during production builds.

For example, in your source code:

@DataSourceDefinition(
    name = "java:app/MyAppDS",
    className = "com.mysql.cj.jdbc.MysqlDataSource",
    url = "${db.url}",
    user = "${db.user}",
    password = "${db.password}"
)

Then configure Maven’s resource filtering (or Gradle’s equivalent) to replace ${db.*} placeholders with environment variables during the production build. Note: This embeds the secret in the compiled class file, so only use this if you trust your build pipeline and artifact storage.

Does Using Application Server Mechanisms Make the Annotation Useless? #

Absolutely not. The annotation’s core value is reducing boilerplate for local development—it lets you spin up a datasource with zero external config, which is a huge win for developer productivity.

In production, application server or cloud-native config mechanisms are designed for security, scalability, and dynamic updates—these are complementary, not competing, with @DataSourceDefinition. The annotation doesn’t need to handle production-grade secrets; it just needs to make local development faster.

Looking Ahead to EL Support #

You’re spot-on that adding EL expression support to @DataSourceDefinition would align it better with Twelve-Factor principles. The Jakarta EE community has discussed this, so it’s possible we’ll see it in future versions. Until then, the above workarounds let you use the annotation safely across environments.

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