Sure, I will do it once I finished the release work of Camel 2.14.0. -- Willem Jiang
Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On September 18, 2014 at 7:05:14 PM, Sergey Beryozkin ([email protected]) wrote: > Hi Willem > > IMHO the pull request created by François is good to be applied, > Can you give me a favor and apply it if you are happy with it too ? > > Cheers, Sergey > On 16/09/14 14:56, Willem Jiang wrote: > > You can fill a JIRA[1] and add the JIRA number into PR comments. > > In this way, Apache JIRA can link the PR recode from github automatically. > > > > [1]https://issues.apache.org/jira/browse/CAMEL > > > > -- > > Willem Jiang > > > > Red Hat, Inc. > > Web: http://www.redhat.com > > Blog: http://willemjiang.blogspot.com (English) > > http://jnn.iteye.com (Chinese) > > Twitter: willemjiang > > Weibo: 姜宁willem > > > > > > > > On September 16, 2014 at 8:43:41 PM, flaroche ([email protected]) wrote: > >> Hi Sergey, > >> > >> I have a pull request ready for it, it was really nothing ;) > >> > >> What I don't see so well now is the opening of an adjustment request. > >> Should I just submit the pull request with the comment in it or is it some > >> more process more strict ? > >> > >> Best regards, > >> > >> François > >> > >> > >> > >> 2014-09-12 23:03 GMT+02:00 Sergey Beryozkin-3 [via Camel] < > >> [email protected]>: > >> > >>> Hi François > >>> > >>> On 12/09/14 14:08, flaroche wrote: > >>> > >>>> Hi everyone, > >>>> > >>>> I had an error a few days ago, and after investigations, here's what it > >>> was > >>>> : > >>>> > >>>> I am calling an endpoint using cxfrs client with the http api. So I have > >>>> something like that in the DSL : > >>>> > >>>> .... > >>>> .setHeader(CxfConstants.CAMEL_CXF_RS_USING_HTTP_API, constant(true)) > >>>> .setHeader(Exchange.HTTP_PATH, simple("/endpoint/${header.myHeader}")) > >>>> .setHeader(Exchange.HTTP_METHOD, constant(POST)) > >>>> .to("cxfrs:bean:myClient") > >>>> .... > >>>> > >>>> This usually works fine. > >>>> > >>>> I had a somewhat nasty error when someone did a copy paste of my server, > >>>> with the variable substitution style (something like > >>> /endpoint/{myVariable}) > >>>> > >>>> at that point, ${header.myHeader} resolved to {myVariable}, thus the url > >>> the > >>>> client will try to resolve is /endpoint/{myVariable}. When trying to > >>> parse > >>>> this URL, CXF will not be happy, since there is no value to replace what > >>> it > >>>> thinks to be a variable, and will throw an IllegalArgumentException with > >>>> message Unresolved variables; only 0 value(s) given for 1 unique > >>>> variable(s). > >>>> > >>>> After looking a bit in the code, I understood better what happens. > >>>> > >>>> In order to avoid that, it would be nice to use the mechanism of CXF to > >>>> replace variables in URI. > >>>> > >>>> In the DSL, we would have something like : > >>>> > >>>> .... > >>>> .setHeader(CxfConstants.CAMEL_CXF_RS_USING_HTTP_API, constant(true)) > >>>> .setHeader(CxfConstants.CAMEL_CXF_RS_VAR_VALUES, > >>>> simple("[${header.myHeader}]")) > >>>> .setHeader(Exchange.HTTP_PATH, constant("/endpoint/{myVariable}")) > >>>> .setHeader(Exchange.HTTP_METHOD, constant("POST")) > >>>> .to("cxfrs:bean:myClient") > >>>> .... > >>>> > >>>> This array would have to be retrieved in the > >>> CxfRsProducer#invokeHttpClient > >>>> (as it is done in the invokeProxyClient method) and passed all the way > >>> to > >>>> the UriBuilder in the WebClient. > >>> > >>> WebClient itself can not be constructed with a URI containing template > >>> vars but its .path() method can take a path with templates alongside an > >>> array of objects. > >>> Another approach could be to use UriBuilder to resolve the templates > >>> first and then create use the resolve address as an effective address to > >>> get a factory bean. > >>> The former option is probably simpler, the code there already does > >>> > >>> if (path != null) { > >>> client.path(path); > >>> } > >>> > >>> Can you please open a minor enhancement request ? A patch would be > >>> welcome too :-), should be few lines only, as you suggested, take the > >>> array, and if it is available, pass it to the client.path() > >>> > >>> Thanks, Sergey > >>> > >>>> > >>>> What do you think of it ? > >>>> > >>>> Best regards, > >>>> > >>>> François > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> View this message in context: > >>> http://camel.465427.n5.nabble.com/CXF-RS-CXF-producers-using-HttpApi-and-URI-substitutions-tp5756419.html > >>> > >>>> Sent from the Camel - Users mailing list archive at Nabble.com. > >>>> > >>> > >>> > >>> -- > >>> Sergey Beryozkin > >>> > >>> Talend Community Coders > >>> http://coders.talend.com/ > >>> > >>> Blog: http://sberyozkin.blogspot.com > >>> > >>> > >>> ------------------------------ > >>> If you reply to this email, your message will be added to the discussion > >>> below: > >>> > >>> http://camel.465427.n5.nabble.com/CXF-RS-CXF-producers-using-HttpApi-and-URI-substitutions-tp5756419p5756457.html > >>> > >>> To unsubscribe from [CXF RS] CXF producers using HttpApi and URI > >>> substitutions, click here > >>> > >>> . > >>> NAML > >>> > >>> > >> > >> > >> > >> > >> -- > >> View this message in context: > >> http://camel.465427.n5.nabble.com/CXF-RS-CXF-producers-using-HttpApi-and-URI-substitutions-tp5756419p5756579.html > >> > >> Sent from the Camel - Users mailing list archive at Nabble.com. > > >
