Log unknown properties when using @ConfigurationProperties

[jkubrynski]

Enhancement

With YAML properties it's too easy to corrupt properties, by just adding whitespace. eg:

# incorrect
spring:
  cloud:
    stream:
      input:
        consumer:
          maxAttempts: 5
          group: api
          
# correct
spring:
  cloud:
    stream:
      input:
        consumer:
          maxAttempts: 5
        group: api

If would be great if regardless the ignoreUnknownFields property, Spring Boot could load a WARN that unmatched property was found. I think that will preserve many stupid mistakes people are making. I can possibly do a PR if you agree it should be implemented.

[wilkinsona]

It's an interesting suggestion but I think it would lead to far too many warnings being generated when a binding target needs ignoreUnknownFields for whatever reason.

IMO, your problem is an argument in favour of using a properties file rather than YAML. Alternatively, your IDE (IDEA, Eclipse, or NetBeans) can already warn you when you use an unknown property.

We could, perhaps, consider debug logging if you still feel that would be useful.

[jkubrynski]

@wilkinsona The problem is that IDE cannot notify about the properties I've mentioned. The only way to solve it during runtime binding. I prefer YAML instead of properties as it is much easier to read and it has a nice structure. I'm not saying to enable it by default, but maybe it could be a parameter set on SpringBootApplication?

[wilkinsona]

I'm not saying to enable it by default, but maybe it could be a parameter set on SpringBootApplication?

It feels much too specialised (and, given the lilkelihood of false positives, only really useful for debugging purposes) to warrant an attribute on SpringBootApplication. If we're going to do this at all, I'd rather use debug logging and enable it by configuring the logging level. Would that still address your need?

[jkubrynski]

Most projects I've seen keep properties in the separate repository than the application. So you have different properties for production than for staging. I'm not sure if many people enable debug logging on production. INFO would be OK, because I can configure filters in ELK stack to figure out such issues.

[wilkinsona]

I'm not sure if many people enable debug logging on production

It would be debug logging for one specific logger that only reported what you're asking for here.

INFO would be OK, because I can configure filters in ELK stack to figure out such issues.

Info doesn't help. It's output by default and I believe there would be too many false positives to be generally useful.

[jkubrynski]

I'll check in our applications how many properties are reported, and then I'll get back to you.