If we set a Map property as deprecated, because it is replaced or removed, the Spring Boot Properties Migrator module, when scanning the application environment and printing diagnostics, does not detect these types of properties.

For example, if we have the custom.logging.log-level property of type java.util.Map defined in the the metadata file as follows:

{
  "name": "custom.logging.log-level",
  "type": "java.util.Map<java.lang.String,java.lang.String>",
  "description": "",
  "deprecation": {
    "level": "error",
    "replacement": "logging.level"
  }
}

and set in the application.yml:

custom:
  logging:
      log-level:
          xx.xxxx.xxxx: INFO

When the spring-boot-properties-migrator module is included and the application is run, the generated report does not show that this property has been replaced by "logging.level".

The same problem can also be encountered with the management.health.status.http-mapping property of the spring-boot-actuator-autoconfigure library:

{
  "name": "management.health.status.http-mapping",
  "type": "java.util.Map<java.lang.String,java.lang.Integer>",
  "sourceType": "org.springframework.boot.actuate.autoconfigure.health.HealthIndicatorProperties",
  "deprecated": true,
  "deprecation": {
    "replacement": "management.endpoint.health.status.http-mapping"
  }
}

spring:
  http:
    encoding:
      charset: UTF-8

management:
  health:
    status:
      http-mapping:
        down: 500
        out_of_service: 503
        warning: 500

The displayed result does not show the deprecated property management.health.status.http-mapping.

[WARN ] 2021-09-02 16:35:49.601 [main]     PropertiesMigrationListener - 
The use of configuration keys that have been renamed was found in the environment:

Property source 'applicationConfig: [classpath:/config/application.yml]':
    Key: spring.http.encoding.charset
        Line: 9
        Replacement: server.servlet.encoding.charset


Each configuration key has been temporarily mapped to its replacement for your convenience. To silence this warning, please update your configuration to use the new keys.

Comment From: dominiccroce

@wilkinsona @jvillarb Starting work on this issue (see fork here). Currently using the above example as a test case, although it seems incomplete. What is the metadata for logging.level? Is it explicitly defined elsewhere in the metadata file, or should it be inferred the both log-level and level are coming from the logging map, so we can infer the new metadata is the same type as the old metadata? That second case seems specific for when deprecation is within the same map as it is in this case. Is my understanding correct that logging is the map and we are trying to rename the field log-level to level?

Currently, my test case is giving a report of 

The use of configuration keys that are no longer supported was found in the environment:

Property source 'custom':
    Key: custom.logging.log-level
        Reason: No metadata found for replacement key 'logging.level'

Is this the report that seen in the original issue? If not, what was the report? Just want to make sure I am truly reproducing the original issue. Thinking desired report looks like:

The use of configuration keys that have been renamed was found in the environment:

Property source 'custom':
    Key: custom.logging.log-level
        Replacement: custom.logging.level

Comment From: snicoll

@dominiccroce thanks for looking into this. I had a quick look at your fork and I don't think that address the issue that's reported here. The problem is that we have a metadata entry for the map, but not for the individual entries (as they are potentially infinite).

Taking back the example above, management.health.status.http-mapping is a deprecated Map property but management.health.status.http-mapping isn't the key. Rather management.health.status.http-mapping.down (for instance) is.

This issue is about checking if the prefix of a key matches a deprecated map entry and then add it to the report. There are multiple ways of doing that and I can't say for sure which one is best. Let me know if you want to pursue this!

Comment From: dominiccroce

Hi @snicoll Thanks for the response. I think makes sense, the map itself is deprecated but individual entries aren't matching since we only look for exact match but not prefix match. I will continue to look at this and adjust my test case accordingly.

Just to confirm, this means that the individual map entries are not explicitly defined in the metadata file, just the map itself and the renamed map will be defined? Also to confirm, this means the key will not be changing, only the map itself is?

Comment From: snicoll

Yep, that's right. Thanks for following up and let us know if you have other questions.

Comment From: dominiccroce

@snicoll I believe I have reproduced the issue in a unit test and now said test is passing. Please see attached PR and we can discuss further there if you have any concerns with the test or implementation.

Comment From: dominiccroce

@snicoll No rush but just curious on when I can get some feedback on my PR?

Comment From: snicoll

@dominiccroce not sure what kind of answer you expect besides "when time permits". I am working on several projects and we're all pretty busy at the moment.

Comment From: dominiccroce

@snicoll Thanks for the response. No worries, this is my first contribution to this project so was just unsure on what to expect for timeline on reviews.