Lesiecki Nicholas wrote:
-1 To supporting two HttpClients going forward. What's the benefit?
Lets rely on HttpClient.
I agree :-)
HttpClient is very much "facaded away" in the current Cactus code. I think that it's right not to expose the HttpClient-API to test writers by providing the HttpURLConnection facade (which is actually provided by HttpClient now)... however we should be using HttpClient more directly in the Cactus internal classes. For example, we currently use UrlUtil to decompose a java.net.URL, just to pass the individual URL components into HttpClient which then reassembles the URL... a lot of overhead and room for bugs. The HttpUtil class, the addition of which triggered this thread, only exists because HttpClient is hidden behind a facade.
Maybe I'm just stating the obvious here ;-)
-chris
Cheers, Nick --- Christopher Lenz <[EMAIL PROTECTED]> wrote:
Vincent Massol wrote:
-----Original Message----- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Lenz Sent: 23 June 2003 13:05 To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-
cactus/framework/src/java/share/org/apache/cactus/client/connector/http
HttpUtil.java JdkConnectionHelper.java HttpClientConnectionHelper.java AbstractConnectionHelper.java
[snip]
This seems to add pretty fragile functionality (query string
manipulation
with encoding etc) to Cactus that should already be provided by Commons-HttpClient. Why are we not using HttpClient for this? Where
does
this code come from and why do we need it?
+1 if this code exists in HttpClient. I'm just not aware of it.
Well, HttpClient probably doesn't have exactly *this* code :-)
We seem to have a lot of stuff that is only required to support both JDK-provided as well as HttpClient-provided HTTP connectivity. If we dropped the JdkConnectionHelper, we might be able to drop stuff like the classes CookieUtil/UrlUtil/HttpUtil, by using the HttpClient-API directly. Although you can configure Cactus to use the JdkConnectionHelper via a system property, that is not documented AFAICT, so the JdkConnectionHelper is probably not used anywhere.
Another thought: we could make Commons-HttpClient an optional dependancy by falling back to the JDK connection helper if HttpClient is not found. In that case, we'd want to keep JdkConnectionHelper, but still have the HttpClientConnectionHelper use the HttpClient API more directly...
-- Christopher Lenz /=/ cmlenz at gmx.de
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
