Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1684
e.g.
```
public class OpenwireMessage extends RefCountMessage {
org.apache.activemq.command.Message message;
public
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1684
@RaiSaurabh this isn't what was quite meant, the idea of implementing
Message is to avoid conversion, so it only needs to convert if cross protocol
on consume. You have only
Github user RaiSaurabh commented on the issue:
https://github.com/apache/activemq-artemis/pull/1684
@michaelandrepearce I have taken your suggestion and implemented it.
Currently, I am testing it will push it in a day or two. I am ensuring that all
the headers are retained on
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1684
@RaiSaurabh seems you've reverted this, are you working on an alternative
solution? Is it worth closing this PR till ready?
---
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1684
On that note, going through the OpenWireConverter that currently converts
OpenWire to Core on produce, there is many places where its not setting the
correct matching
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1684
So here I would either suggest that these are not copied to core message
when converting to core, but if need because of consuming with openwire
consumer then probably better
Github user RaiSaurabh commented on the issue:
https://github.com/apache/activemq-artemis/pull/1684
@michaelandrepearce @clebertsuconic
Please correct me if my understanding is wrong. I checked the code of
OpenwireMesageConverter when we send a message using client if comes to
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1684
If this is specific to OpenWire headers, should this not be stripped during
converting open wire messages within the open wire protocol support module, it
shouldn't be leaking
