> > We have extended properties in AMQP as we cannot modify the message on the > server. >
I guess you mean the AMQPMessage.extraProperties here (?). I would use these extraProperties in such a way for an incoming AMQP message: - read passed on tracing context from deliveryAnnotations - create *child* tracing context and store its ID in the extraProperties of the AMQP message. - if the message is to be delivered to a non-AMQP consumer, the "AmqpCoreConverter.toCore" conversion will preserve the tracing ID by putting it in the CoreMessage.properties. One caveat here: I have to store it as a *bytes* property inside the extraProperties (otherwise there would be an exception in AmqpCoreConverter.toCore()). Using a String property would be more convenient here and would prevent necessary conversions because the aforementioned "opentracing-contrib/java-jms" module also stores the context in String properties in a JMS message. If you see no issues with supporting any kind of TypedProperty for the extraProperties, I would create a Github issue to change the extraProperties handling in AmqpCoreConverter.toCore() accordingly. For the other requirement in this scenario (reading/setting AMQP delivery annotations), I have created https://issues.apache.org/jira/browse/ARTEMIS-2045 along with a PR.
