Hide Forgot
Date of First Response: 2010-02-25 14:05:27 Help Desk Ticket Reference: https://enterprise.redhat.com/issue-tracker/356581 project_key: SOA message.getHeader().getCall().getTo().getAddr().getAddress() returns a different format after CP02 release For example) GA, CP01: jms://soa01:1200/queue/myRequestQueue CP02: jms:soa01:1200#queue/myRequestQueue While the API is public, the contents of the EPR are implementation dependent and should be treated as opaque. There are no guarantees that the format will remain the same. This is a request to describe above notice on ESB documentation.
Link: Added: This issue depends JBESB-2971
Link: Added: This issue related JBESB-2502
Approved for SOA 4.3 CP03.
Please review the following draft text that I have added to the Migration section of the Release Notes: 2.2.1. Format of End Point Reference Contents Has Changed The contents of message.getHeader().getCall().getTo().getAddr().getAddress() are now returned in a different format than that in the 4.3GA and 4.3.CP01 releases. Previously, the format was: jms://soa01:1200/queue/myRequestQueue but now it is: jms:soa01:1200#queue/myRequestQueue Note that, whilst the API is public, the contents of the end-point reference are implementation-specific. Always regard them as opaque because there is no guarantee the format will remain the same.
Taro, I have actually reworded it slightly in order to make it read better. The new wording is below but can you also please give a little information about who was modifying the format and why? Was it a particular customer? Many thanks. 2.2.1. Format of End Point Reference Contents Has Changed The contents of message.getHeader().getCall().getTo().getAddr().getAddress() are now returned in a different format than that in the 4.3GA and 4.3.CP01 releases. Previously, the format was in the form of: jms://soa01:1200/queue/myRequestQueue but now it is: jms:soa01:1200#queue/myRequestQueue Users should not modify End-Point Reference formats directly because they are specific to implementations of the API. There is no guarantee the format will remain the same for them.
David, the fix on JBESB-2502 affected the behavior and per Kevin, this is as a consequence of the fix and is necessary to support different JMS providers. So not for a particular customer.
Thanks for clarifying that for me, Taro. Much appreciated.