Harmonize configuration properties that accept a comma-separated list of values

[snicoll]

Looking at #42472, I found odd that we'd use a String for a property that's declared as a "comma-separated list of". Then I noticed that MessageSourceProperties has the same pattern for the basename property.

Looking at our code base, most of these properties are a List or an array, with a few exceptions. I am wondering if we shouldn't harmonize this across the code base so that it's always a collection.

[wilkinsona]

I had the same thought when briefly looking at #42472.

Consistently using List or similar sounds good to me, particularly where the target of the property is a collection-like type and we're having to do something like StringUtils.commaDelimitedListToStringArray when setting it.

[philwebb]

I think this code probably pre-dates the binder rewrite so +1 to moving to a List<String>. That will also allow the YAML list syntax to work.

[wilkinsona]

As part of this, I'm going to revise the property descriptions to just say "list" rather than "comma-separated list". My hope is that this will make it a bit more clear that YAML's list syntax can be used.

[defaultbranch]

Thanks guys for keeping improving Spring/Spring Boot! This change sadly was not fully explained in Spring Boot 3.4 Release Notes.

Looking at commit fae3cd1 I understand why my previous setup fails with SpringBoot 3.4.0:

    private SpringLiquibase springLiquibase(DataSource dataSource, LiquibaseProperties properties) {
        var liquibase = new SpringLiquibase();
        liquibase.setDataSource(dataSource); 
        // ^--- the one thing I want to change, everything below is just keeping the default
        liquibase.setChangeLog(properties.getChangeLog());
        liquibase.setContexts(properties.getContexts());
        // ^--- now an ERROR; need to convert list to comma-sep string now
        liquibase.setDefaultSchema(properties.getDefaultSchema());
        liquibase.setDropFirst(properties.isDropFirst());
        liquibase.setShouldRun(properties.isEnabled());
        liquibase.setLabelFilter(properties.getLabelFilter());
        // ^--- now an ERROR; need to convert list to comma-sep string now
        liquibase.setChangeLogParameters(properties.getParameters());
        liquibase.setRollbackFile(properties.getRollbackFile());
        return liquibase;
    }

But maybe my way of setting up Liquibase is odd, so I guess I should instead use a Customizer<Liquibase> bean, mentioned in the Spring Boot 3.4 Release Notes...

[wilkinsona]

We don't consider the getters and setters on Boot's @ConfigurationProperties classes to be public API. This is noted in the documentation:

The properties that map to @ConfigurationProperties classes available in Spring Boot, which are configured through properties files, YAML files, environment variables, and other mechanisms, are public API but the accessors (getters/setters) of the class itself are not meant to be used directly.

But maybe my way of setting up Liquibase is odd, so I guess I should instead use a Customizer<Liquibase> bean, mentioned in the Spring Boot 3.4 Release Notes...

A Customizer<Liquibase> won't meet your needs as the DataSource needs to be set on the SpringLiquibase instance not the Liquibase instance that it creates. You can use @LiquibaseDataSource to define a DataSource @Bean bean that will be used by Liquibase.