If a property is of type Map there are some restrictions on the key. If the key contains a ., the key must be wrapped to teach the binder what is the key and what is the next navigation target.
This is now applicable when binding to a scalar value, logging.level is a good example of that.
While working on #14139, I've noticed we have define a ServiceLevelAgreementBoundary type that represents a scalar value. There is a management.metrics.distribution.sla property that maps a meter ID to an array of such type.
A meter ID has typically a dot in it but this is working fine because the target type is an array. If the target type is a pojo, no binding of a meter with a dot happens unless it's wrapped.
There is a sample project to showcase concretely what happens: https://github.com/snicoll-scratches/test-binding-singular-pojo
It would be nice if we had an annotation that teaches the binder that the target type is a scalar value which would have two side effects:
- The binder could offer binding of key with a dot without requiring the wrapping. This can be useful for things where we know there is high chance the key will have a dot in it
- The IDE can poke at the source code for the type and stop complaining that the part after the dot doesn't represent a valid property of said type.
IntelliJ IDEA properly implements what is supposed to happen so SLA keys are shown as invalid at the moment:
Comment From: mbhave
I wonder if we can just remove this constraint and rely on the converter being able to convert for it to be considered a scalar value.
Comment From: snicoll
That works but that's more work for the IDE to figure out whether it can accept nested traversal or not.
Comment From: philwebb
Possibly somewhat related #13404