属性名称闹的一场乌龙事件

最近有一个需求，系统要根据启动参数加载不同权限的数据源，代码就位之后，开启了自测。

刚开始测的是默认场景下数据源加载情况，这个时候一切正常。

后来开始测试特定场景下的case，这个时候出现问题了，发现数据源并没有按照我想要的情况加载。第一时间就想到了是不是启动参数读取的问题。

排查了下发现还真是启动参数读取有问题，没有按照指定的启动参数注入。

启动参数：-Ddb.privilege=r -Denv=dev ……

其中db.privilege是这次新加的，看了配置类，感觉一切正常。
配置类代码：

public interface ISysDbConfig {
    String getGlobalJdbcDriverClassName();

    String getGlobalJdbcUrl();

    String getGlobalJdbcUsername();

    String getGlobalJdbcPassword();

    String getGlobalPublicKey();

    String getJdbcDriverClassName();

    String getGlobalJdbcMaxWait();

    String getGlobalJdbcMaxIdle();

    String getGlobalJdbcMaxActive();

    String getGlobalJdbcMinIdle();

    String getGlobalJdbcInitialSize();

    String getDbPrivilege();
}

@Data
@ConfigurationProperties(prefix = PropertiesNameConstant.DB, ignoreInvalidFields = true)
@Component
public class DbConfigBean implements ISysDbConfig {
    @Value("${global.jdbc.url:#{null}}")
    private String globalJdbcUrl;
    @Value("${global.jdbc.username:#{null}}")
    private String globalJdbcUsername;
    @Value("${global.jdbc.password:#{null}}")
    private String globalJdbcPassword;
    @Value("${global.publicKey:#{null}}")
    private String globalPublicKey;
    @Value("${global.jdbc.driverClassName:#{null}}")
    private String globalJdbcDriverClassName;
    ……
    @Value("${privilege:rw}")
    private String dbPrivilege;
}

顿时有些纳闷，什么情况？

后来尝试把代码改成：

    @Value("${db.privilege:rw}")
    private String dbPrivilege;

注入成功。

俗话说当局者迷，旁观者清。决定求助于同事。

同事说你ConfigurationProperties注解混用了，默认值应该直接改成：private String dbPrivilege = "rw";

一句惊醒梦中人。

在我上面的代码中，ConfigurationProperties注解是根据指定的前缀+属性名称进行注入的，Value注解是根据指定的参数名进行注入的，正常情况下二者取其一即可。

而在我最原始的代码中，两个都不搭边，所以就没有注入进去……很尴尬。

修改后的代码为：

@Data
@ConfigurationProperties(prefix = PropertiesNameConstant.DB, ignoreInvalidFields = true)
@Component
public class DbConfigBean implements ISysDbConfig {
    ......
    private String privilege = "rw";
}

重新启动项目，一切正常。

就很粗心。

嗯，知道错了，下次还犯。

除非注明，否则均为李锋镝的博客原创文章，转载必须以链接形式标明本文链接

本文链接：https://www.lifengdi.com/article/exception/4472