Jorge Esteban Quilcate Otoya

@me3x , could you re-enable this IT that was validating this issue: `ITJms_1_1_TracingMessageConsumer:253` If that one goes green we should be good to merge.

@me3x take a look to the last `bytesMessage.reset()` on `PropertyFilter#resetBytesMessageProperties`, it is closing the message again; triggering failure later when injecting context at the end: ```java void handleReceive(Message message) {...

Could you add a test to show this? As you can see we have this issues based on jms design choices and bug with activemq bytes message, and we are...

@me3x I won't be able to help much if we don't have a test-case to check this scenario, I'm sorry. If we want to cover this case where [this change](https://github.com/openzipkin/brave/pull/1042/files#diff-fcac8ed18c129e381a445860fea0b7a5R69-R75)...

@me3x I've second thoughts about my previous comments. I realize now that we are only "touching" message content on this PR and not in the existing implementation where we deal...

@me3x right, so we can do the write back right after the `clearBody` isn't it? This is much better. What do you think on moving things to `TracingConsumer`? We can...

@adriancole still waiting for the next ActiveMQ client release to be available. I will create a PR with the changes and notes about target versions on README, and close this...

@frosiere yes, that's the approach we have follow so far to avoid breaking previous versions.

@jcchavezs I think so. Will give a try.

@jcchavezs in order to apply a similar boundary as java reporter, we will need to batch based on bytes size, instead of number of elements. We can check this on...