-
Notifications
You must be signed in to change notification settings - Fork 40.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document when and how to use bracket notation when binding to a map #13506
Comments
I think this is, essentially, the same limitation as #13404 is tracking. You can get the # the zipkin service name
camel.zipkin.server-service-mappings.[*]=service1
camel.zipkin.client-service-mappings.[*]=service2 |
Given that we've got #13404 to make this easier, I think we should use this issue to document the current situation. There's a brief mention of bracket notation on the wiki, but I can't find any mention in the reference documentation. |
sounds good. somehow I thought brackets were about lists, but anyway
escaping like this sounds fine to me.
|
Is this behavior expected: logging:
level:
org.springframework.kafka.listener[KafkaMessageListenerContainer$ListenerConsumer]: info and logging:
level:
org.springframework.kafka.listener.[KafkaMessageListenerContainer$ListenerConsumer]: info (with and without They both work. |
yes this is expected behavior. |
Camel's zipkin spring boot thing uses wildcard mappings to properties like this:
The corresponding
@ConfigurationProperties
would receive a map entry for the wildcard into a map field like this:private Map<String, String> clientServiceMappings
The last version this worked on was Spring Boot 2.0 M7. Afterwards, this mapping fails with the following exception:
So that you don't have to build camel, you can paste the below into a start.spring.io app, setting the above as application.properties
The text was updated successfully, but these errors were encountered: