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.
--- Begin Message ---
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]>
--- End Message ---
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
