ConfigurationMetadataProperty name not stripped with same source types

[jvalkeal]

Sample for this issue is in https://github.com/jvalkeal/randomstuff/tree/master/metadatanaming which uses 2.1.4.RELEASE.

Running a sample app prints (ConfigurationMetadataProperty.getId() / ConfigurationMetadataProperty.getName()):

spring.rabbitmq.listener.direct.acknowledge-mode / acknowledge-mode
spring.rabbitmq.listener.direct.auto-startup / auto-startup
spring.rabbitmq.listener.direct.consumers-per-queue / consumers-per-queue
spring.rabbitmq.listener.direct.default-requeue-rejected / default-requeue-rejected
spring.rabbitmq.listener.direct.idle-event-interval / idle-event-interval
spring.rabbitmq.listener.direct.missing-queues-fatal / missing-queues-fatal
spring.rabbitmq.listener.direct.prefetch / prefetch
spring.rabbitmq.listener.direct.retry.enabled / enabled
spring.rabbitmq.listener.direct.retry.initial-interval / initial-interval
spring.rabbitmq.listener.direct.retry.max-attempts / max-attempts
spring.rabbitmq.listener.direct.retry.max-interval / max-interval
spring.rabbitmq.listener.direct.retry.multiplier / multiplier
spring.rabbitmq.listener.direct.retry.stateless / stateless
spring.rabbitmq.listener.simple.acknowledge-mode / acknowledge-mode
spring.rabbitmq.listener.simple.auto-startup / auto-startup
spring.rabbitmq.listener.simple.concurrency / concurrency
spring.rabbitmq.listener.simple.default-requeue-rejected / default-requeue-rejected
spring.rabbitmq.listener.simple.idle-event-interval / idle-event-interval
spring.rabbitmq.listener.simple.max-concurrency / max-concurrency
spring.rabbitmq.listener.simple.missing-queues-fatal / missing-queues-fatal
spring.rabbitmq.listener.simple.prefetch / prefetch
spring.rabbitmq.listener.simple.retry.enabled / spring.rabbitmq.listener.simple.retry.enabled
spring.rabbitmq.listener.simple.retry.initial-interval / spring.rabbitmq.listener.simple.retry.initial-interval
spring.rabbitmq.listener.simple.retry.max-attempts / spring.rabbitmq.listener.simple.retry.max-attempts
spring.rabbitmq.listener.simple.retry.max-interval / spring.rabbitmq.listener.simple.retry.max-interval
spring.rabbitmq.listener.simple.retry.multiplier / spring.rabbitmq.listener.simple.retry.multiplier
spring.rabbitmq.listener.simple.retry.stateless / spring.rabbitmq.listener.simple.retry.stateless
spring.rabbitmq.listener.simple.transaction-size / transaction-size

As you can see every property under spring.rabbitmq.listener.simple.retry group will not strip groupId from its name.

When you i.e. use ConfigurationMetadataRepositoryJsonBuilder manually to build repository to get access to ConfigurationMetadataProperty's, RawConfigurationMetadata is getting slightly confused when it's trying to strip group id from a fully qualified property name to set a simple name.

Below is metadata for spring.rabbitmq.listener.direct.retry.enabled and spring.rabbitmq.listener.simple.retry.enabled which have a same sourceType.

{
  "properties": [
    {
      "name": "spring.rabbitmq.listener.direct.retry.enabled",
      "type": "java.lang.Boolean",
      "description": "Whether publishing retries are enabled.",
      "sourceType": "org.springframework.boot.autoconfigure.amqp.RabbitProperties$ListenerRetry",
      "defaultValue": false
    },
    {
      "name": "spring.rabbitmq.listener.simple.retry.enabled",
      "type": "java.lang.Boolean",
      "description": "Whether publishing retries are enabled.",
      "sourceType": "org.springframework.boot.autoconfigure.amqp.RabbitProperties$ListenerRetry",
      "defaultValue": false
    }
  ]
}

Issue seem to be RawConfigurationMetadata.getSource() which returns first ConfigurationMetadataSource matching a source type. As seen above, these two properties have different group but same sourceType, thus first match is returned. However as seen in below, when actual ConfigurationMetadataItem name is tried to re-set to a simple name(stripping group id), group prefix doesn't match, thus stripping doesn't happen.

spring-boot/spring-boot-project/spring-boot-tools/spring-boot-configuration-metadata/src/main/java/org/springframework/boot/configurationmetadata/RawConfigurationMetadata.java

Lines 83 to 86 in ddc8b6f

	if (hasLength(groupId) && id.startsWith(dottedPrefix)) {
	String name = id.substring(dottedPrefix.length());
	item.setName(name);
	}

I created this issue from spring-cloud/spring-cloud-dataflow-ui#769 and as @snicoll asked to create a sample to provide more details. MetadataResolver class in a sample is pretty much how we're using boot metadata in a dataflow space.

[philwebb]

ListenerRetry is mapped to two different sources because it's in DirectContainer and SimpleContainer which both extend AmqpContainer. This setup is fairly rare and I guess we just didn't account for it.

[jvalkeal]

@philwebb AmqpContainer was just given as an example to re-prod this issue. This same thing happens other places, especially in dataflow apps, deployers, etc where some metadata properties extends same classes.

[philwebb]

@jvalkeal Understood. It just took me a while to work out why the same sourceType was registered with two different names and I wanted to add some notes to the issue to jog my memory later.

[jvalkeal]

@philwebb I had a chat with Stephane when he was just to board his flight and I think he was planning to poke around things while being on a cloud.

[philwebb]

OK, I'll assign it to him so nobody else picks it up.