Re: Discussion about using JMS transport with CXFRS
Hi Sergey, I'm trying to create a WebClient instance by setting the address with jms uri to configure the endpoint jms address. But now I have trouble to setup the message context of REQUEST_URI in WebClient as this uri is not jms uri which I used to create the WebClient. How can I set REQUEST_URI without affect the ENDPOINT_ADDRESS by using WebClient API ? If not, I'm going to update the WebClient API for it. On Tue May 29 22:40:34 2012, Willem Jiang wrote: On Tue May 29 22:33:59 2012, Sergey Beryozkin wrote: Hi Willem On 29/05/12 14:53, Willem Jiang wrote: Hi, I just have a chance to go through the missing feature of JMS transport to support cxfrs frontend. Current JMS transport doesn't send out Message.REQUEST_URI and Message.HTTP_REQUEST_METHOD properties as the HTTP transport does. So it hard for use the use the cxfrs frontend with JMS transport. My question is do we need to transfer other properties which could be used by cxfrs frondend? The above properties are defaulted to "/" and "POST" respectively but can be customized via JMS properties Thanks, I will try to write some test tomorrow. And The AbstractClient is tend to use HttpConnection to get the headers for build the response, it stops the user to leverage other transports. We may need to update this part of code. +1. I did few changes to address https://issues.apache.org/jira/browse/CXF-3562, but I will prioritize on it after 2.6.1 is out. It is also needed for the future async support, alternative HTTP stacks support, etc, so it's time to start addressing it sounds good. Cheers, Sergey Any thoughts? -- Willem -- CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com FuseSource Web: http://www.fusesource.com Blog: http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang Weibo: willemjiang -- Willem -- CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com FuseSource Web: http://www.fusesource.com Blog:http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang Weibo: willemjiang
Re: Discussion about using JMS transport with CXFRS
On Tue May 29 22:33:59 2012, Sergey Beryozkin wrote: Hi Willem On 29/05/12 14:53, Willem Jiang wrote: Hi, I just have a chance to go through the missing feature of JMS transport to support cxfrs frontend. Current JMS transport doesn't send out Message.REQUEST_URI and Message.HTTP_REQUEST_METHOD properties as the HTTP transport does. So it hard for use the use the cxfrs frontend with JMS transport. My question is do we need to transfer other properties which could be used by cxfrs frondend? The above properties are defaulted to "/" and "POST" respectively but can be customized via JMS properties Thanks, I will try to write some test tomorrow. And The AbstractClient is tend to use HttpConnection to get the headers for build the response, it stops the user to leverage other transports. We may need to update this part of code. +1. I did few changes to address https://issues.apache.org/jira/browse/CXF-3562, but I will prioritize on it after 2.6.1 is out. It is also needed for the future async support, alternative HTTP stacks support, etc, so it's time to start addressing it sounds good. Cheers, Sergey Any thoughts? -- Willem -- CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com FuseSource Web: http://www.fusesource.com Blog:http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang Weibo: willemjiang
Re: Discussion about using JMS transport with CXFRS
Hi Willem On 29/05/12 14:53, Willem Jiang wrote: Hi, I just have a chance to go through the missing feature of JMS transport to support cxfrs frontend. Current JMS transport doesn't send out Message.REQUEST_URI and Message.HTTP_REQUEST_METHOD properties as the HTTP transport does. So it hard for use the use the cxfrs frontend with JMS transport. My question is do we need to transfer other properties which could be used by cxfrs frondend? The above properties are defaulted to "/" and "POST" respectively but can be customized via JMS properties And The AbstractClient is tend to use HttpConnection to get the headers for build the response, it stops the user to leverage other transports. We may need to update this part of code. +1. I did few changes to address https://issues.apache.org/jira/browse/CXF-3562, but I will prioritize on it after 2.6.1 is out. It is also needed for the future async support, alternative HTTP stacks support, etc, so it's time to start addressing it Cheers, Sergey Any thoughts? -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
