http bug
in [Java Programming]
|
From: Daniel Pitts on 20 Jan 2010 17:28 Lothar Kimmeringer wrote: > Daniel Pitts wrote: > >> I often find the standard HttpUrlConnection lacking, and usually go with >> apache commons HttpClient instead. You have more control of the >> process, if you care, but it also "works" out-of-the-box if you don't >> want to configure it as much. > > The last time I checked, GetMethod and PostMethod were two > classes sharing a lot of methods but not a common superclass. > So you end up with code like this > > if (performGet) { > methodGet = new GetMethod(host + url); > methodGet.setQueryString(query); > methodGet.setDoAuthentication(authNeeded); > methodGet.getParams().setParameter("http.socket.timeout", > Integer.valueOf(timeout)); > methodGet.getParams().setParameter( > HttpMethodParams.RETRY_HANDLER, retryhandler); > methodGet.setRequestHeader("Connection", "keep-alive"); > methodGet.setRequestHeader("Cache-Control", "no-cache"); > } > else { > methodPost = new PostMethod(host + url); > methodPost.setRequestHeader("Connection", "keep-alive"); > methodPost.setDoAuthentication(authNeeded); > methodPost.getParams().setParameter("http.socket.timeout", > Integer.valueOf(timeout)); > methodPost.getParams().setParameter( > HttpMethodParams.RETRY_HANDLER, retryhandler); > methodPost.setRequestHeader("Cache-Control", "no-cache"); > } > if (methodGet != null){ > statuscode = client.executeMethod(methodGet); > } > else{ > statuscode = client.executeMethod(methodPost); > } > > and so on. If you have a specific HTTP-session to handle > programmatically, HttpClient is nice, but if you have to > build different HTTP-requests in dependence of external > configurations, you have a lot of duplicate code that > is prone to errors. > > > Regards, Lothar Last time I checked, they both implement HttpMethod and are derived from HttpMethodBase. Perhaps you had a really old version, or misinterpreted something else. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Lew on 20 Jan 2010 18:34 Lothar Kimmeringer wrote: >> The last time I checked, GetMethod and PostMethod were two >> classes sharing a lot of methods but not a common superclass. >> So you end up with code like this >> >> if (performGet) { >> methodGet = new GetMethod(host + url); >> methodGet.setQueryString(query); >> methodGet.setDoAuthentication(authNeeded); >> methodGet.getParams().setParameter("http.socket.timeout", >> Integer.valueOf(timeout)); >> methodGet.getParams().setParameter( >> HttpMethodParams.RETRY_HANDLER, retryhandler); >> methodGet.setRequestHeader("Connection", "keep-alive"); >> methodGet.setRequestHeader("Cache-Control", "no-cache"); >> } >> else { >> methodPost = new PostMethod(host + url); >> methodPost.setRequestHeader("Connection", "keep-alive"); >> methodPost.setDoAuthentication(authNeeded); >> methodPost.getParams().setParameter("http.socket.timeout", >> Integer.valueOf(timeout)); >> methodPost.getParams().setParameter( >> HttpMethodParams.RETRY_HANDLER, retryhandler); >> methodPost.setRequestHeader("Cache-Control", "no-cache"); >> } >> if (methodGet != null){ >> statuscode = client.executeMethod(methodGet); >> } >> else{ >> statuscode = client.executeMethod(methodPost); >> } >> >> and so on. If you have a specific HTTP-session to handle >> programmatically, HttpClient is nice, but if you have to >> build different HTTP-requests in dependence of external >> configurations, you have a lot of duplicate code that >> is prone to errors. > Daniel Pitts wrote: > Last time I checked, they both implement HttpMethod and are derived from > HttpMethodBase. Perhaps you had a really old version, or misinterpreted > something else. > I'm not seeing either one, nor 'HttpMethodBase', nor 'HttpMethod' in the HttpClient Javadocs. I find 'HttpGet' and 'HttpPost', which inherit from 'HttpRequestBase' and implement 'HttpMessage', and seem roughly equivalent to what you're talking about. <http://hc.apache.org/httpcomponents-client/httpclient/apidocs/ index.html> From <http://hc.apache.org/>: "HttpComponents Client is a successor of and replacement for Commons HttpClient 3.x. Users of Commons HttpClient are strongly encouraged to upgrade. ... "Commons HttpClient 3.x codeline is nearing the end of life. All users of Commons HttpClient 3.x are strongly encouraged to upgrade to HttpClient 4.0." -- Lew
From: Daniel Pitts on 20 Jan 2010 19:53 Lew wrote: > Lothar Kimmeringer wrote: >>> The last time I checked, GetMethod and PostMethod were two >>> classes sharing a lot of methods but not a common superclass. >>> So you end up with code like this >>> >>> if (performGet) { >>> methodGet = new GetMethod(host + url); >>> methodGet.setQueryString(query); >>> methodGet.setDoAuthentication(authNeeded); >>> methodGet.getParams().setParameter("http.socket.timeout", >>> Integer.valueOf(timeout)); >>> methodGet.getParams().setParameter( >>> HttpMethodParams.RETRY_HANDLER, retryhandler); >>> methodGet.setRequestHeader("Connection", "keep-alive"); >>> methodGet.setRequestHeader("Cache-Control", "no-cache"); >>> } >>> else { >>> methodPost = new PostMethod(host + url); >>> methodPost.setRequestHeader("Connection", "keep-alive"); >>> methodPost.setDoAuthentication(authNeeded); >>> methodPost.getParams().setParameter("http.socket.timeout", >>> Integer.valueOf(timeout)); >>> methodPost.getParams().setParameter( >>> HttpMethodParams.RETRY_HANDLER, retryhandler); >>> methodPost.setRequestHeader("Cache-Control", "no-cache"); >>> } >>> if (methodGet != null){ >>> statuscode = client.executeMethod(methodGet); >>> } >>> else{ >>> statuscode = client.executeMethod(methodPost); >>> } >>> >>> and so on. If you have a specific HTTP-session to handle >>> programmatically, HttpClient is nice, but if you have to >>> build different HTTP-requests in dependence of external >>> configurations, you have a lot of duplicate code that >>> is prone to errors. > > Daniel Pitts wrote: >> Last time I checked, they both implement HttpMethod and are derived from >> HttpMethodBase. Perhaps you had a really old version, or misinterpreted >> something else. >> > > I'm not seeing either one, nor 'HttpMethodBase', nor 'HttpMethod' in > the HttpClient Javadocs. I find 'HttpGet' and 'HttpPost', which > inherit from 'HttpRequestBase' and implement 'HttpMessage', and seem > roughly equivalent to what you're talking about. > <http://hc.apache.org/httpcomponents-client/httpclient/apidocs/ > index.html> > > From <http://hc.apache.org/>: > "HttpComponents Client is a successor of and replacement for Commons > HttpClient 3.x. Users of Commons HttpClient are strongly encouraged to > upgrade. ... > "Commons HttpClient 3.x codeline is nearing the end of life. All users > of Commons HttpClient 3.x are strongly encouraged to upgrade to > HttpClient 4.0." > > -- > Lew Our codebase has been using HttpClient 3.1, so that is why the discrepancy. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Arne Vajhøj on 20 Jan 2010 20:14 On 20-01-2010 14:53, Lothar Kimmeringer wrote: > Daniel Pitts wrote: >> I often find the standard HttpUrlConnection lacking, and usually go with >> apache commons HttpClient instead. You have more control of the >> process, if you care, but it also "works" out-of-the-box if you don't >> want to configure it as much. > > The last time I checked, GetMethod and PostMethod were two > classes sharing a lot of methods but not a common superclass. Sure? HttpClient 2.0.2 has a common super class. > So you end up with code like this > > if (performGet) { > methodGet = new GetMethod(host + url); > methodGet.setQueryString(query); > methodGet.setDoAuthentication(authNeeded); > methodGet.getParams().setParameter("http.socket.timeout", > Integer.valueOf(timeout)); > methodGet.getParams().setParameter( > HttpMethodParams.RETRY_HANDLER, retryhandler); > methodGet.setRequestHeader("Connection", "keep-alive"); > methodGet.setRequestHeader("Cache-Control", "no-cache"); > } > else { > methodPost = new PostMethod(host + url); > methodPost.setRequestHeader("Connection", "keep-alive"); > methodPost.setDoAuthentication(authNeeded); > methodPost.getParams().setParameter("http.socket.timeout", > Integer.valueOf(timeout)); > methodPost.getParams().setParameter( > HttpMethodParams.RETRY_HANDLER, retryhandler); > methodPost.setRequestHeader("Cache-Control", "no-cache"); > } > and so on. If you have a specific HTTP-session to handle > programmatically, HttpClient is nice, but if you have to > build different HTTP-requests in dependence of external > configurations, you have a lot of duplicate code that > is prone to errors. Most HTTP request receivers are either POST or GET anyway. I can not imagine sending the exact same data to an URL just with different method should be that common. Arne
From: Arne Vajhøj on 20 Jan 2010 20:16
On 20-01-2010 18:34, Lew wrote: > Lothar Kimmeringer wrote: >>> The last time I checked, GetMethod and PostMethod were two >>> classes sharing a lot of methods but not a common superclass. >>> So you end up with code like this >>> >>> if (performGet) { >>> methodGet = new GetMethod(host + url); >>> methodGet.setQueryString(query); >>> methodGet.setDoAuthentication(authNeeded); >>> methodGet.getParams().setParameter("http.socket.timeout", >>> Integer.valueOf(timeout)); >>> methodGet.getParams().setParameter( >>> HttpMethodParams.RETRY_HANDLER, retryhandler); >>> methodGet.setRequestHeader("Connection", "keep-alive"); >>> methodGet.setRequestHeader("Cache-Control", "no-cache"); >>> } >>> else { >>> methodPost = new PostMethod(host + url); >>> methodPost.setRequestHeader("Connection", "keep-alive"); >>> methodPost.setDoAuthentication(authNeeded); >>> methodPost.getParams().setParameter("http.socket.timeout", >>> Integer.valueOf(timeout)); >>> methodPost.getParams().setParameter( >>> HttpMethodParams.RETRY_HANDLER, retryhandler); >>> methodPost.setRequestHeader("Cache-Control", "no-cache"); >>> } >>> if (methodGet != null){ >>> statuscode = client.executeMethod(methodGet); >>> } >>> else{ >>> statuscode = client.executeMethod(methodPost); >>> } >>> >>> and so on. If you have a specific HTTP-session to handle >>> programmatically, HttpClient is nice, but if you have to >>> build different HTTP-requests in dependence of external >>> configurations, you have a lot of duplicate code that >>> is prone to errors. >> > > Daniel Pitts wrote: >> Last time I checked, they both implement HttpMethod and are derived from >> HttpMethodBase. Perhaps you had a really old version, or misinterpreted >> something else. > > I'm not seeing either one, nor 'HttpMethodBase', nor 'HttpMethod' in > the HttpClient Javadocs. I find 'HttpGet' and 'HttpPost', which > inherit from 'HttpRequestBase' and implement 'HttpMessage', and seem > roughly equivalent to what you're talking about. > <http://hc.apache.org/httpcomponents-client/httpclient/apidocs/ > index.html> Which you explain yourself: > From<http://hc.apache.org/>: > "HttpComponents Client is a successor of and replacement for Commons > HttpClient 3.x. Users of Commons HttpClient are strongly encouraged to > upgrade. ... > "Commons HttpClient 3.x codeline is nearing the end of life. All users > of Commons HttpClient 3.x are strongly encouraged to upgrade to > HttpClient 4.0." Version 4.0 is relative new. And the completely broke existing code, so a lot of people will use 2.x and 3.x for a long time, because they don't want to rewrite the code. Arne |