Defaults within device registration can cause JMS incompatibility

[DanielMaier-BSI]

When a device gets registered with defaults, the keys of these defaults are freely choosable by the user. Hono protocol adapters use these defaults and adds them as AMQP application properties. However this might break JMS compatibility as there is no check or conversion of forbidden characters like '-'.

One way to prevent this would be to just document these restrictions. Another solution would be to replace forbidden characters or restrict allowed characters.

To be honest I am not convinced by any of the suggested solutions. Just documenting would not prevent from being used wrongly. It is likely that the user who creates the devices does not even know by which client the AMQP messages get consumed. Replacement might be non-transparent and annoying for use cases where no JMS gets used. The same applies for restricting allowed characters (Perhaps there are existing applications/frameworks that need a specific property key). Perhaps the appropriate place to replace the forbidden chars would be on JMS client side.

What do you think? Any better suggestions?

[pellmann]

I would vote for documentation of this restriction in the Device Registration API and a checkDefaultsJMSCompatibility (something like that) config property with true as default in the base device registry implementation (which than prohibits such defaults).

[DanielMaier-BSI]

Sounds reasonable from hono perspective for me.

In an environment where exist many tenants and device creators don't necessarily know if the northbound messages get consumed by JMS client, the only way would be to leave checkDefaultsJMSCompatibility configured with true. With this global configuration nobody would be able to set e.g. content-type as default property.

Another solution would be to "duplicate" default properties in AbstractProtocolAdapterBase and replace forbidden characters in one copy and perhaps prefix them somehow (similar to JMS vendor properties). With this solution only the developer of JMS based northbound application has to care about all this stuff. Of course hono needs to handle somehow now if somebody creates a default property with forbidden chars and the same property with replaced chars already.