is it possible to add my own Properties in message ApplicationProperties without "applicationProperties." prefix in properties' keys message?

[polaraditia]

My app needs to send some app properties in message as the other existing and running apps that act as receiver needs information that I put in ApplicationProperties. The code is quite simple

message.ApplicationProperties["key2"] = 42
message.ApplicationProperties["key3"] = true

I am using ActiveMQ Artemis. We tested and the message sent successfully and receiver can receive my message, but we found the properties part somehow go-amqp library itself add prefix "applicationProperties." in my properties keys.

The other sender, C# app created using NMS Library can write its own properties like this and the message properties' keys result is same as the code without prefix "applicationProperties."

ITextMessage item = session.CreateTextMessage();
item.Properties["Number"] = 1;
item.Properties["Total"] = 1;
item.Properties["key2"] = 42;

Unfortunately, we can't modified the exising receiver and other sender to change its code to process new properties with prefix. Since the receiver is hardcoded, it can only read properties with "key2" or "key3" key only.

I have look sender.go, message.go, encoding.go, buffer.go files in this repo to figuring out maybe there are some code that add "applicationProperties" prefix that I need to remove, but I have no luck and still not found that code.

Is it possible to write our own properties in the message without the prefix with this library?

Thank you

[jhendrixMSFT]

The application properties section adheres to the AMQP 1.0 spec, and there is no "applicationProperties" prefix being written into the message as that's not mandated per the spec (see the marshalling code here).

I assume the C# NMS library is this one. I took a brief look at this, and it provides a level of abstraction over an AMQP message. I'm not sure how exactly item.Properties[] maps to an AMQP message. You might also need to ensure that messages you create using this module conform to the JMS Mapping 1.0 spec as linked from that repo.

[jhendrixMSFT]

Please ping back if you have further questions.