As we now have a way to ignore properties, we should review the @ConfigurationProperties annotated @Bean methods if we want to ignore properties.

Here are the prefixes I found which come from a @ConfigurationProperties annotated method:

  • spring.datasource.dbcp2
  • spring.datasource.hikari
  • spring.datasource.oracleucp
  • spring.datasource.tomcat
  • spring.groovy.template.configuration

Comment From: wilkinsona

That matches up with these exclusions:

https://github.com/spring-projects/spring-boot/blob/6fcbf14fc07f828d95dc247db065b6a77931fb3f/spring-boot-project/spring-boot-autoconfigure/build.gradle#L278-L285

Hopefully we should be able to remove them once the ignored properties are in place.

Comment From: mhalbritter

I've played around with that here: https://github.com/mhalbritter/spring-boot/tree/mh/43988-review-configurationproperties-annotated-bean-methods-for-ignored-properties

I've added all the Hikari properties to the additional-spring-configuration-metadata.json either in the properties section (only added name and a dummy description) or added the non-bindable properties to the ignored array. Then I removed spring.datasource.hikari.* from the checkSpringConfigurationMetadata configuration.

Antora creates a row for every hikari property if the hikari prefix is removed from org.springframework.boot.build.context.properties.DocumentConfigurationProperties#dataPrefixes.

For the description: I've copied the JavaDoc description from HikariDataSource into the additional-spring-configuration-metadata.json. I guess that's the way to go for the remaining ones, too?

Comment From: wilkinsona

Sorry, I was probably overly optimistic about being able to get rid of those exclusions. For this issue, I think we should focus on ignoring the properties that it does not make sense to expose in the metadata. We can address the descriptions separately if we decide we want to tackle that too.

The properties you've ignored look good to me. I wondered about keeping the following:

  • spring.datasource.hikari.driver-class-name
  • spring.datasource.hikari.jdbc-uri
  • spring.datasource.hikari.password
  • spring.datasource.hikari.username

However, I don't think it's necessary as they all have equivalent spring.datasource.* properties that are preferred. @snicoll's more familiar than I am with the subtleties here with things like jdbc-url vs url. Does this sound right to you, Stephane?

I also noticed that we have a couple of groups in the metadata that don't make sense:

  • spring.datasource.hikari.health-check-registry
  • spring.datasource.hikari.metric-registry

There are no properties in either of these groups. This looks like a bug in the annotation processor to me as I don't think it should create an empty group. We can tackle that in a separate issue.

Comment From: mhalbritter

// Edit: Ah nvm, i misread the code and the JavaDoc of the superclass class clarifies that it doesn't apply for PropertiesJdbcConnectionDetails. Ignore the comment :)

Thanks Andy. We have a HikariJdbcConnectionDetailsBeanPostProcessor in place which post-processes HikariDataSource beans and overrides jdbcUrl, username, password and driverClassName with values coming from the JdbcConnectionDetails. Which most likely will be a PropertiesJdbcConnectionDetails and would then use the spring.datasource.* values. That's the reason I included them in the ignore list, because they don't have an effect anyway.