Description
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.
I created this issue from spring-attic/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.