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.
