https://github.com/cloudevents/spec/issues/460
Â
We have an issue in CNCF CloudEvents about maps not being permitted in application-properties. I remember weâve run up against that ourselves recently.
Â
A few questions:
Â
- Does anyone remember why that constraint was put in?
- Do existing implementations enforce the constraint?
- How do I cheat?
a) Some participants expressed concern about having more complex types in the values, in particular because application properties were designed to be "filterable" and performing matching/evaluation on complex types was thought to be burdensome. There is also the issue that popular messaging APIs such as JMS do not allow for complex types as values in the application headers.
b) It may be that brokers that were originally built to be purely JMS brokers may have issues here if they do some sort of internal conversion; I'm pretty sure Qpid Broker-J does not enforce, I can't speak for others.
c) Off the top of my head:
option 1. Encode the map a JSON, or some other encoding of your choice;Â
option 2. we define a spec for an "enhancement" capability such that two containers exchange a connection capability for "COMPLEX_APPLICATION_PROPERTY_VALUES" or some such. If the other side offers this capability then you know you can send maps in values (intermediaries would have fun with this I guess as potentially they would have to deal with the issue of "invalid" messages being transited into enforcing containers).
option 3. add a message annotation to messages with complex values "complex_props" -> true . or something. An intermediary not understanding that is supposed to reject if it doesn't recognise the annotation (and intermediaries that don't do that enforcement probably also don't validate the application properties).
I'm sure others will have alternative suggestions
-- Rob