fyi -----Original Message----- From: Eric Johnson [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 12, 2002 17.09 PM To: Pill, Juergen Subject: Re: Slide and Jakarta-commons-httpClient
<<patch.zip>> So that others may see the patch, it is attached, but compressed to reduce its size. All feedback welcome. * Eric Johnson Pill, Juergen wrote: >Hello friends of the Slide API, > >Thanks to Eric Johnson, I received a patch for the Slide API to work >together with the current version of the HttpClient. He committed and tested >all the necessary changed in HttpClient already for us and made the >necessary adaptations to the Slide API. Currently we are having in our GUMP >night build compile errors due to the fact, that GUMP compiles against the >current version of the HttpClient, but the Slide API is coded against an >(integrated and) old version of the HttpClient. > >If there are no objections I would start to apply those patches and remove >the local copy of the HttpClient in Slide. The HttpClient working group is >currently voting to go to HttpClient 2.0 Alpha 2. > >I have attached Eric's e-mail describing the applied changes just in case. > >The test suite and possibly the JSP implementation would need to be changed >to. I would volunteer for the test suite. > >Best regards, > >Juergen > > > <<Ported client tools to use latest HttpClient library>> > > > -----Original Message----- >From: Eric Johnson [mailto:[EMAIL PROTECTED]] >Sent: Thursday, December 12, 2002 16.06 PM >To: Pill, Juergen >Subject: Re: Slide and Jakarta-commons-httpClient > > << File: httpclient.port.patch >> Juergen, > >Attached is a patch against the latest trunk code. You may or may not >want to edit out the build.xml file portion of the patch. > >In any event, there are a number of deprecation warnings, and a JDK 1.4 >build produces a lot of Javadoc problems - but I tried to keep my focus >as narrow as possible, and only do the task at hand. > >I will gladly submit this patch to the group as soon as I get a public >request to do so. Given the size of the patch, I think it should be >integrated in a public manner, and to alert others that might be >interested in seeing the port through, who might also have something to >contribute. > >I don't claim that it is bug free - merely an improvement over its >predecessor (which didn't compile). > >-Eric. > > > > > > > ------------------------------------------------------------------------ > > Subject: > Ported client tools to use latest HttpClient library > From: > Eric Johnson <[EMAIL PROTECTED]> > Date: > Fri, 11 Oct 2002 19:26:22 +0100 > To: > Jakarta Slide <[EMAIL PROTECTED]> > > >To whom might be interested, > >I have just completed a migration of the latest client libraries to the >latest version of commons HttpClient. > >There are a number of issues that came up, some of which deserve >probably some feedback on this list. At the end of this email, I >outline the changes that were necessary. I'll submit a patch when >encouraged to do so. There are a bunch of areas in which I just >"cobbled" together the solution, for example, copying the >commons-logging.jar to the right place, rather than having the build do >so for me. > >Issues: >- HttpClient no longer exposes getHost() and getPort() functions. I >have submitted a patch for this to HttpClient. > >- XMLResponseMethodBase might not be an appropriate name for this class, >as I had to add functionality related to generating a "request" here >(see 5 below). > >- "debug" is no longer supported on HttpClient. This seems appropriate >to me, in that all logging is instead routed via commons-logging, >however, this meant that I commented out any code in methods where the >"debug" member variable was checked. This might not be the optimal way >to solve this particular problem. > >- HttpException no longer has a getStatusCode(), but instead has a >getReasonCode(), which means something slightly different, and is not >actually used by the constructor of HttpException. This meant that >there were a few places where the code seemed to want an exception >thrown with a status code (like SC_UNAUTHORIZED), so I explicitly set >the reason to be the status code in a handful of places and then threw >an exception, so that existing Client code would work properly (23). > >- WebdavResource.setEncodeURLs() was problematic in that the "HttpState" >no longer keeps track of an encoding (21). > >- Bug in WebdavResource.unlockMethod()? Was using "defaultOwner", but >changed this to use the same logic to compute owner as lockMethod(). > >-Bug in WebdavResource.unlockMethod(String)? The parameter being passed >here by the client is the path, not the owner. > >- WebdavSession was implementing ConnectorInterceptor, which no longer >exists. I simply removed all the implemented functions. Is this a problem? > >Outline of changes: >1) State changed to HttpState >2) HttpMethodBase.name member variable no longer exists. Instead the >getName() function must be implemented for "method". Constructors for >all methods changed appropriately as well. >3) HttpMethodBase.generateHeaders() becomes addRequestHeaders() >4) HttpMethodBase.setHeader() becomes setRequestHeader() >5) HttpMethodBase.generateQuery() is no longer called while generating >the query. To get around this, I implemented an override of both >HttpMethodBase.getRequestContentLength() and >HttpMethodBase.writeRequestBody() in XMLResponseMethodBase, and >introduced a new function called generateRequestBody. >6) HttpMethodBase.parseResponse() changed signatures - adjusted all >"methods" appropriately. >7) HttpMethodBase.getStatusCode() is deprecated - substituted the >non-deprecated getStatusLine().getStatusCode() >8) Commented out all code that would run based on a non-zero setting for >the old HttpMethodBase.debug variable. Also removed calls to set debug >level >9) Removed spurious CheckinMethod.setHeader() and generateQuery functions. >10) Removed spurious CheckoutMethod.setHeader() function. >11) Changed references of HttpException.getStatusCode() to getReasonCode() >12) Where "Credentials" was instantiated earlier, I substituted the new >subclass UsernamePasswordCredentials. >13) HttpMethodBase.getData() becomes getResponseBodyAsStream() in a >variety of places. >14) Changed parseResponse() to take additional parameters HttpState and >HttpConnection. >15) Used change from 14 for LockMethod.parseResponse(). >16) Options.processResponseHeaders() - changed signature to match new >signature in HttpMethodBase. >17) "headers.get()" replaced with getResponseHeader() in (16) >18) Put.uploadFiles() now calls method.setRequestBody() instead of >method.sendData >19) UncheckoutMethod.generateQuery() removed. >20) WebdavResource.isTheClient() changed to get the credentials from a >UsernamePasswordCredentials - if that is what is on hand. >21) WebdavResource.setEncodeURLs() - removed contents of function. >22) HttpClient.executeMethod() returns the status code, took advantage >of that. >23) WebdavResource.propfindMethod() now checks the status code and >throws an HttpException if the status is not SC_MULTI_STATUS >24) WebdavResource.unlockMethod() >25) WebdavSession - removed all functions that implemented the >ConnectionInterceptor. > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > >
patch.zip
Description: Binary data
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
