Hi Robbie, Do you mean this? --> https://github.com/apache/qpid-jms/blob/0af503a9bb7af3c7e25e1a16c42ab0b30919a5a8/qpid-jms-client/src/main/java/org/apache/qpid/jms/message/JmsBytesMessage.java#L412-L420
On Mon, Nov 4, 2019 at 11:31 AM Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > I dont believe Qpid JMS has a comparable behaviour. The getBody() > method (added in JMS2) copies the underlying payload to a fresh array, > the various read<Foo> style accessors operate on a different input > stream. There isnt a similar 'get content' property with side effects > behaviour that I see. You can get the entire content, or read content > from the message byte stream in various ways and reset the message if > you want to read any earlier content with them again. > > Robbie > > On Sat, 2 Nov 2019 at 21:42, Krzysztof <h4v...@gmail.com> wrote: > > > > Hi, > > > > Recently on nms-amqp bug tracker the following issue was raised > > > > https://issues.apache.org/jira/browse/AMQNET-625 > > > > I've confirmed that the described behavior actually takes place, and may > be > > quite annoying especially if one is debugging the code and try to inspect > > the content of the bytes message (as c# properties are automatically > > evaluated when you try to inspect an object using watch window) the > message > > is corrupted. There is no way to read its content ever again unless we > > reset the underlying stream. > > > > I've confirmed that this behavior is in line with qpid-jms implementation > > (at least ReadBytes() method we are invoking in Content getter behaves in > > the same way). But my question is, is this really desired or described > > somewhere in jms spec? As java JMS implementation of BytesMessage doesn't > > have a Content getter it shouldn't be a case. > > > > I know that with the underlying provider (at least in nms-amqp and > > AmqpNetLite) we could support multiple reads quite easily if we decouple > > the Content getter from the state of the stream that's manipulated by all > > Read* methods. > > > > What do you think? > > > > Regards, > > Krzysztof Porebski >
