On Thu, Jan 17, 2013 at 12:43 PM, Robbie Gemmell <robbie.gemm...@gmail.com> wrote: >> > Yep, 3272
Gotcha. > Seperate as in store the provided String in a field which is separate from > the UUID in the header where we would normally store the passed in message > id value, and return this when getJMSMessageID is called. Thanks for clarifying. It makes sense. On a separate note : All though (based on the updated info) we don't need to consider preserving the original message-id for now, this may become important in the future. Consider a message being routed through a federated network, where it takes several hops before reaching the endpoint. One of those hops could very well be implemented using a JMS client. In this case the Qpid client will overwrite the message-id with a new one. The hops are merely forwarding/routing agents and in that sense tampering with the original message properties may not be a good idea. In such a situation it would be useful to have a configurable way to ensure the send-impl doesn't override the message id. I think we will be seeing such use cases in the near future. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
