You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2004/09/20 22:50:20 UTC
ATTN Open-source projects using HttpClient
As far as I know the following projects rely on HttpClient 2.0 as a
required or optional dependency
* Apache Jakarta Slide (http://jakarta.apache.org/slide/)
* Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
* Apache Axis (http://ws.apache.org/axis/)
* Apache XML-RPC (http://ws.apache.org/xmlrpc/)
* Spring Framework (http://www.springframework.org/)
* HtmlUntit (http://htmlunit.sourceforge.net/)
* XINS (http://xins.sourceforge.net/)
I just wonder if any of the projects' committers are currently
subscribed to or monitor this mail list?
We would love to know if there are any plans to evaluate HttpClient 3.0,
or any migration plans already. What can we do to make the transition,
if planned, easier?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by Dion Gillard <di...@gmail.com>.
Jelly is going through a 1.0 release at the moment, but I think it's
worth looking at it before then.
On Tue, 21 Sep 2004 08:56:21 +0200, Oleg Kalnichevski <ol...@apache.org> wrote:
> I apologize for forgetting about Maven and Jelly. Are there any plans to
> evaluate HttpClient 3.0? We are trying to get some feedback about the
> new 3.0 API before the call the API freeze.
>
> Oleg
>
>
>
> On Tue, 2004-09-21 at 03:07, Dion Gillard wrote:
> > Jelly and Maven both use httpclient.
> >
> >
> > On Mon, 20 Sep 2004 22:50:20 +0200, Oleg Kalnichevski <ol...@apache.org> wrote:
> > > As far as I know the following projects rely on HttpClient 2.0 as a
> > > required or optional dependency
> > >
> > > * Apache Jakarta Slide (http://jakarta.apache.org/slide/)
> > > * Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
> > > * Apache Axis (http://ws.apache.org/axis/)
> > > * Apache XML-RPC (http://ws.apache.org/xmlrpc/)
> > > * Spring Framework (http://www.springframework.org/)
> > > * HtmlUntit (http://htmlunit.sourceforge.net/)
> > > * XINS (http://xins.sourceforge.net/)
> > >
> > > I just wonder if any of the projects' committers are currently
> > > subscribed to or monitor this mail list?
> > >
> > > We would love to know if there are any plans to evaluate HttpClient 3.0,
> > > or any migration plans already. What can we do to make the transition,
> > > if planned, easier?
> > >
> > > Oleg
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
>
>
> ---------------------------------------------------------------------
>
>
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by Oleg Kalnichevski <ol...@apache.org>.
I apologize for forgetting about Maven and Jelly. Are there any plans to
evaluate HttpClient 3.0? We are trying to get some feedback about the
new 3.0 API before the call the API freeze.
Oleg
On Tue, 2004-09-21 at 03:07, Dion Gillard wrote:
> Jelly and Maven both use httpclient.
>
>
> On Mon, 20 Sep 2004 22:50:20 +0200, Oleg Kalnichevski <ol...@apache.org> wrote:
> > As far as I know the following projects rely on HttpClient 2.0 as a
> > required or optional dependency
> >
> > * Apache Jakarta Slide (http://jakarta.apache.org/slide/)
> > * Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
> > * Apache Axis (http://ws.apache.org/axis/)
> > * Apache XML-RPC (http://ws.apache.org/xmlrpc/)
> > * Spring Framework (http://www.springframework.org/)
> > * HtmlUntit (http://htmlunit.sourceforge.net/)
> > * XINS (http://xins.sourceforge.net/)
> >
> > I just wonder if any of the projects' committers are currently
> > subscribed to or monitor this mail list?
> >
> > We would love to know if there are any plans to evaluate HttpClient 3.0,
> > or any migration plans already. What can we do to make the transition,
> > if planned, easier?
> >
> > Oleg
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by Dion Gillard <di...@gmail.com>.
Jelly and Maven both use httpclient.
On Mon, 20 Sep 2004 22:50:20 +0200, Oleg Kalnichevski <ol...@apache.org> wrote:
> As far as I know the following projects rely on HttpClient 2.0 as a
> required or optional dependency
>
> * Apache Jakarta Slide (http://jakarta.apache.org/slide/)
> * Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
> * Apache Axis (http://ws.apache.org/axis/)
> * Apache XML-RPC (http://ws.apache.org/xmlrpc/)
> * Spring Framework (http://www.springframework.org/)
> * HtmlUntit (http://htmlunit.sourceforge.net/)
> * XINS (http://xins.sourceforge.net/)
>
> I just wonder if any of the projects' committers are currently
> subscribed to or monitor this mail list?
>
> We would love to know if there are any plans to evaluate HttpClient 3.0,
> or any migration plans already. What can we do to make the transition,
> if planned, easier?
>
> Oleg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by Eric Johnson <er...@tibco.com>.
Well, er, I care.
At least, I care about the Slide *client* library. I don't know if the
server stuff has a dependency on HttpClient.
I've been meaning to add it to my list to check how much it changes.
I'll do that this week. If I don't do it this week, it will be several
more weeks after that before I can look at it again....
-Eric.
Oleg Kalnichevski wrote:
>Sadly, no one seems to care. What do we do?
>
>Oleg
>
>
>On Mon, 2004-09-20 at 22:50, Oleg Kalnichevski wrote:
>
>
>>As far as I know the following projects rely on HttpClient 2.0 as a
>>required or optional dependency
>>
>>* Apache Jakarta Slide (http://jakarta.apache.org/slide/)
>>* Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
>>* Apache Axis (http://ws.apache.org/axis/)
>>* Apache XML-RPC (http://ws.apache.org/xmlrpc/)
>>* Spring Framework (http://www.springframework.org/)
>>* HtmlUntit (http://htmlunit.sourceforge.net/)
>>* XINS (http://xins.sourceforge.net/)
>>
>>I just wonder if any of the projects' committers are currently
>>subscribed to or monitor this mail list?
>>
>>We would love to know if there are any plans to evaluate HttpClient 3.0,
>>or any migration plans already. What can we do to make the transition,
>>if planned, easier?
>>
>>Oleg
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by Dion Gillard <di...@gmail.com>.
Oleg,
after adding codec as another dependency and upgrading to 3.0-alpha2,
the jelly taglibs were all still working.
HTH,
On Tue, 28 Sep 2004 09:50:59 +1000, Dion Gillard <di...@gmail.com> wrote:
> Oleg, I do care.
>
> I've just unfortunately been moving offices, had servers offline, had
> a firewall issue etc etc.
>
> I should get to testing 3.0 with jelly rsn
>
>
>
>
> On Mon, 27 Sep 2004 20:43:56 +0200, Oleg Kalnichevski <ol...@apache.org> wrote:
> > Sadly, no one seems to care. What do we do?
> >
> > Oleg
> >
> >
> >
> >
> > On Mon, 2004-09-20 at 22:50, Oleg Kalnichevski wrote:
> > > As far as I know the following projects rely on HttpClient 2.0 as a
> > > required or optional dependency
> > >
> > > * Apache Jakarta Slide (http://jakarta.apache.org/slide/)
> > > * Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
> > > * Apache Axis (http://ws.apache.org/axis/)
> > > * Apache XML-RPC (http://ws.apache.org/xmlrpc/)
> > > * Spring Framework (http://www.springframework.org/)
> > > * HtmlUntit (http://htmlunit.sourceforge.net/)
> > > * XINS (http://xins.sourceforge.net/)
> > >
> > > I just wonder if any of the projects' committers are currently
> > > subscribed to or monitor this mail list?
> > >
> > > We would love to know if there are any plans to evaluate HttpClient 3.0,
> > > or any migration plans already. What can we do to make the transition,
> > > if planned, easier?
> > >
> > > Oleg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> > >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> http://www.multitask.com.au/people/dion/
>
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by Dion Gillard <di...@gmail.com>.
Oleg, I do care.
I've just unfortunately been moving offices, had servers offline, had
a firewall issue etc etc.
I should get to testing 3.0 with jelly rsn
On Mon, 27 Sep 2004 20:43:56 +0200, Oleg Kalnichevski <ol...@apache.org> wrote:
> Sadly, no one seems to care. What do we do?
>
> Oleg
>
>
>
>
> On Mon, 2004-09-20 at 22:50, Oleg Kalnichevski wrote:
> > As far as I know the following projects rely on HttpClient 2.0 as a
> > required or optional dependency
> >
> > * Apache Jakarta Slide (http://jakarta.apache.org/slide/)
> > * Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
> > * Apache Axis (http://ws.apache.org/axis/)
> > * Apache XML-RPC (http://ws.apache.org/xmlrpc/)
> > * Spring Framework (http://www.springframework.org/)
> > * HtmlUntit (http://htmlunit.sourceforge.net/)
> > * XINS (http://xins.sourceforge.net/)
> >
> > I just wonder if any of the projects' committers are currently
> > subscribed to or monitor this mail list?
> >
> > We would love to know if there are any plans to evaluate HttpClient 3.0,
> > or any migration plans already. What can we do to make the transition,
> > if planned, easier?
> >
> > Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by stack <st...@archive.org>.
Oleg Kalnichevski wrote:
>> <>...
>> St.Ack,
>>
>> Could you retest HttpClient 3.0a3 with IBM JRE and let us know if the
>> problem still persists?
>
No problem. Soon as its available.
> }
>
> public int execute(HttpState state, HttpConnection conn)
> throws HttpException, IOException {
> return super.execute(state, new HeritixConnectionWrapper(conn));
> }
>}
>
>It's ugly but should prevent you from having to patch HttpClient. A
>better solution would be a pluggable HttpConnection implementation. This
>will have to wait until 4.0, though
>
>
I think we'll wait on 4.0. Doing the wrap, while possible, means
bringing forward to the subclass loads of code from the parent. Current
(ugly) overlay with little patch seems more maintainable.
Thanks again,
St.Ack
>Oleg
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by Oleg Kalnichevski <ol...@apache.org>.
> That'd be grand if its possible (We like the IBM JVMs' speed and more
> detailed thread dumps). We used to subclass httpclient so we could do
> the below, moving the setting of the timeout till after the open.
> HttpClient 3.0 now sets timeout, etc., after the open seemingly so our
> subclass is no longer necessary (Hurray!).
St.Ack,
Could you retest HttpClient 3.0a3 with IBM JRE and let us know if the
problem still persists?
> HttpRecorder duplicates all sent and received to files on disk. It wraps the (buffered) socket streams with input/output streams that do the duplication. Subsequently, the file is fed to a set of processors to with as they wilt. Link extraction is main task performed by processors.
>
> We need to record what was sent over the wire preserving order and all bytes sent back and forth (We're trying to archive the web). If there's a less intrusive way of getting what we need, we'd love to hear of it.
>
One possibility would be some thing like that:
public class HeritixMethod extends GetMethod {
class HeritixConnectionWrapper extends HttpConnection {
...
}
public int execute(HttpState state, HttpConnection conn)
throws HttpException, IOException {
return super.execute(state, new HeritixConnectionWrapper(conn));
}
}
It's ugly but should prevent you from having to patch HttpClient. A
better solution would be a pluggable HttpConnection implementation. This
will have to wait until 4.0, though
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by stack <st...@archive.org>.
Oleg Kalnichevski wrote:
>
>We have already had a few reports regarding IBM JSSE semantical
>incompatibilities with Sun JSSE. It appears IBM JSSE implementation
>unlike Sun's does not like attempts to set socket parameters when the
>socket is closed. I believe it is clearly a bug in IBM JSSE but we can
>think of working it around in HttpClient.
>
>
>
That'd be grand if its possible (We like the IBM JVMs' speed and more
detailed thread dumps). We used to subclass httpclient so we could do
the below, moving the setting of the timeout till after the open.
HttpClient 3.0 now sets timeout, etc., after the open seemingly so our
subclass is no longer necessary (Hurray!).
// HERITRIX: Moved this timeout to after connection.open.
// connection.setSoTimeout(soTimeout);
if (!connection.isOpen()) {
connection.setConnectionTimeout(connectionTimeout);
connection.open();
// HERITRIX: Move socket timeout here. It used to be done
// before connection.open.
connection.setSoTimeout(soTimeout);
> ...
>
>>+ inputStream = httpRecorder.inputWrap((InputStream)
>>+ (new BufferedInputStream(socket.getInputStream(),
>>+ inbuffersize)));
>>+ outputStream = httpRecorder.outputWrap((OutputStream)
>>+ (new BufferedOutputStream(socket.getOutputStream(),
>>+ outbuffersize)));
>>+ }
>>+ // END HERITRIX change.
>>+
>>
>>
>>
>
>What does exactly httpRecorder do? Probably we could think of a less
>intrusive way of getting the same thing done.
>
>
HttpRecorder duplicates all sent and received to files on disk. It wraps the (buffered) socket streams with input/output streams that do the duplication. Subsequently, the file is fed to a set of processors to with as they wilt. Link extraction is main task performed by processors.
We need to record what was sent over the wire preserving order and all bytes sent back and forth (We're trying to archive the web). If there's a less intrusive way of getting what we need, we'd love to hear of it.
...
>>+ value = new StringBuffer(line.substring(colon +
>>1).trim()); }
>>- name = line.substring(0, colon).trim();
>>- value = new StringBuffer(line.substring(colon +
>>1).trim()); + // END HERITRIX change.
>> }
>>
>>
>>
>
>This is a known problem. Basically it appears there's no one right way
>to parse HTTP status line and headers that fits all type of
>applications. Our plan is to provide a plugin mechanism for custom HTTP
>parsers in the version 4
>
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25468
>
>
>
Sounds good.
Thanks again for the software.
Yours,
St.Ack
>Cheers,
>
>Oleg
>
>***************************************************************************************************
>The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
>***************************************************************************************************
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by Oleg Kalnichevski <ol...@bearingpoint.com>.
Hi St.Ack,
Your feedback is really appreciated. I am quite happy that we now have
one less development list to spam ;)
See my comments inline
> The upgrade took way longer than I anticipated, a couple of days rather
> than a couple of hours. While some of the time was spent on refactoring
> only slightly related to the httpcilent upgrade and testing to see all
> httpclient used features still work post upgrade, the bulk of the time
> was spent on redoing our auth system to fit the redesigned httpclient
> auth system. I had trouble figuring out how things work now in the
> absence of example. Our usage is a little out-of-the-ordinary in that we
> manage own store of credentials and manage when to load them onto a
> httpmethod. Previous, HttpAuthenticator would select the scheme for
> me. Now it seems like I have to do it myself using AuthChallengeParser
> and then iterate over the returns. In general the new auth system
> changes look to be for the best.
I am not sure if that's going to be of help in your particular case, I
just want to note that one may replace the standard authentication
schemes with custom ones and provide additional custom schemes, if so is
desired:
http://jakarta.apache.org/commons/httpclient/3.0/authentication.html#Custom%20authentication%20scheme
> The IBM SSL socket timeout issues I'm seeing when I get an SSLSocket
> with a timeout (I set the timeout by getting a socket with the null arg
> constructor then doing an SSLSocket$connect with a timeout). The
> exceptions do not happen when I use SUN JVM 1.4.2. These are probably
> IBM JVM issues but I'll list them here anyways:
>
> 1. The IBM JVM 141 (cxia321411-20030930) NPEs setting the NoTcpDelay.
> Is anyone else seeing this?
> java.lang.NullPointerException
> at com.ibm.jsse.bf.setTcpNoDelay(Unknown Source)
> at
> org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:683)
> at
> org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1328)
>
> 2. Using the IBM JVM 142, its saying SSL connection not open when we go
> to use inputstreams.
> java.net.SocketException: Socket is not connected
> at java.net.Socket.getInputStream(Socket.java:726) at
> com.ibm.jsse.bs.getInputStream(Unknown Source)
> at
> org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:715)
> at
> org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1328)
>
We have already had a few reports regarding IBM JSSE semantical
incompatibilities with Sun JSSE. It appears IBM JSSE implementation
unlike Sun's does not like attempts to set socket parameters when the
socket is closed. I believe it is clearly a bug in IBM JSSE but we can
think of working it around in HttpClient.
> By way of feedback on the 3.0 API, I'll describe the two places where
> the API is lacking regards our requirements forcing us to do yucky
> overlays. First some context. The crawler must record the response
> headers and response content exactly as it comes back over the wire and
> its supposed to be tenacious.
>
> Regards recording exactly what the server sent us, we overlay
> HttpConnection with a version that wraps the socket input and output
> streams. Here's the diff:
>
> +// HERITRIX import.
> +import org.archive.util.HttpRecorder;
> +
> /**
> * An abstraction of an HTTP {@link InputStream} and {@link OutputStream}
> * pair, together with the relevant attributes.
> @@ -676,7 +679,6 @@
> highly interactive environments, such as some client/server
> situations. In such cases, nagling may be turned off through
> use of the TCP_NODELAY sockets option." */
> -
> socket.setTcpNoDelay(this.params.getTcpNoDelay());
> socket.setSoTimeout(this.params.getSoTimeout());
>
> @@ -701,8 +703,23 @@
> if (inbuffersize > 2048) {
> inbuffersize = 2048; }
> - inputStream = new
> BufferedInputStream(socket.getInputStream(), inbuffersize);
> - outputStream = new
> BufferedOutputStream(socket.getOutputStream(), outbuffersize);
> + // START HERITRIX Change
> + HttpRecorder httpRecorder = HttpRecorder.getHttpRecorder();
> + if (httpRecorder == null) {
> + inputStream = new BufferedInputStream(
> + socket.getInputStream(), inbuffersize);
> + outputStream = new BufferedOutputStream(
> + socket.getOutputStream(), outbuffersize);
> + } else {
> + inputStream = httpRecorder.inputWrap((InputStream)
> + (new BufferedInputStream(socket.getInputStream(),
> + inbuffersize)));
> + outputStream = httpRecorder.outputWrap((OutputStream)
> + (new BufferedOutputStream(socket.getOutputStream(),
> + outbuffersize)));
> + }
> + // END HERITRIX change.
> +
>
What does exactly httpRecorder do? Probably we could think of a less
intrusive way of getting the same thing done.
> The other overlay we make is of HttpParser so we can persist through a
> bad header parse:
>
> /apache/commons/httpclient/HttpParser.java
> src/java/org/apache/commons/httpclient/HttpParser.java ---
> /home/stack/bin/commons-httpclient-3.0-alpha2/src/java/org/apache/commons/httpclient/HttpParser.java
> 2004-09-19 13:41:05.000000000 -0700 +++
> src/java/org/apache/commons/httpclient/HttpParser.java 2004-09-29
> 14:23:03.000000000 -0700
> @@ -185,11 +185,21 @@
> // Otherwise we should have normal HTTP header line
> // Parse the header name and value
> int colon = line.indexOf(":");
> + // START HERITRIX Change
> + // Don't throw an exception if can't parse. We want to
> keep
> + // going even though header is bad. Rather, create
> + // pseudo-header.
> if (colon < 0) { - throw new
> ProtocolException("Unable to parse header: " + line);
> + // throw new ProtocolException("Unable to parse
> header: " ++ // line);
> - throw new ProtocolException("Unable to parse
> header: " + line); + // throw new
> ProtocolException("Unable to parse header: " ++
> // line);
> + name = "HttpClient-Bad-Header-Line-Failed-Parse";
> + value = new StringBuffer(line);
> +
> + } else {
> + name = line.substring(0, colon).trim();
> + value = new StringBuffer(line.substring(colon +
> 1).trim()); }
> - name = line.substring(0, colon).trim();
> - value = new StringBuffer(line.substring(colon +
> 1).trim()); + // END HERITRIX change.
> }
>
This is a known problem. Basically it appears there's no one right way
to parse HTTP status line and headers that fits all type of
applications. Our plan is to provide a plugin mechanism for custom HTTP
parsers in the version 4
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25468
Cheers,
Oleg
***************************************************************************************************
The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by Michael Becke <be...@u.washington.edu>.
Hi St.Ack,
Many thanks for taking the time to make such a detailed response. I
haven't had time to fully digest (no pun intended) your message, but
I'll take a look at it again in the morning. In the mean time I've
added Heritrix to the applications page in CVS, which will be added to
the site next time it's published.
Mike
On Sep 29, 2004, at 7:53 PM, stack wrote:
> Oleg Kalnichevski wrote:
>
>> Thanks, Adam
>>
>> Should we decide to go on a spamming spree, these may also become
>> potential victims ;-)
>>
>>
> Let me preempt the spam (smile).
>
> I'm part of the webgroup at the Internet Archive (archive.org). We've
> been using httpclient at the heart of our open source crawler Heritrix
> (crawler.archive.org) for near on a year now (I've added on the end a
> submission for the httpclient applications page). I've just upgraded
> HEAD to use 3.0alpha2 and was going to say a few words about the
> experience and how its running.
>
> Heads up. The following message is a little long.
>
> The upgrade took way longer than I anticipated, a couple of days
> rather than a couple of hours. While some of the time was spent on
> refactoring only slightly related to the httpcilent upgrade and
> testing to see all httpclient used features still work post upgrade,
> the bulk of the time was spent on redoing our auth system to fit the
> redesigned httpclient auth system. I had trouble figuring out how
> things work now in the absence of example. Our usage is a little
> out-of-the-ordinary in that we manage own store of credentials and
> manage when to load them onto a httpmethod. Previous,
> HttpAuthenticator would select the scheme for me. Now it seems like I
> have to do it myself using AuthChallengeParser and then iterate over
> the returns. In general the new auth system changes look to be for
> the best. It just cost time exploring. Thereafter, the remainder was
> spent undoing our own custom retry to instead use a custom
> HttpMethodRetryHandler that is now part of httpclient core, study of
> the new configuration system to ensure correct usage, undoing old ways
> of specifying preferences, and exploiting new preference granularity
> particularly where it could make the crawler more robust
> (UNAMBIGUOUS_STATUS_LINE, STRICT_TRANSFER_ENCODING,
> STATUS_LINE_GARBAGE_LIMIT, etc).
>
> With the new lib in place, we pass all of our little suite of
> selftests (includes Auth tests of logins and Basic and Digest Auth),
> and random broad crawling shows performance as comparable with the
> only weird exceptions having to do with timeouts on IBM SSL Sockets.
> Later I should have more detailed feedback on performance and
> robustness.
>
> The IBM SSL socket timeout issues I'm seeing when I get an SSLSocket
> with a timeout (I set the timeout by getting a socket with the null
> arg constructor then doing an SSLSocket$connect with a timeout). The
> exceptions do not happen when I use SUN JVM 1.4.2. These are probably
> IBM JVM issues but I'll list them here anyways:
>
> 1. The IBM JVM 141 (cxia321411-20030930) NPEs setting the NoTcpDelay.
> Is anyone else seeing this?
> java.lang.NullPointerException
> at com.ibm.jsse.bf.setTcpNoDelay(Unknown Source)
> at
> org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:
> 683)
> at
> org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpCo
> nnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1328)
>
> 2. Using the IBM JVM 142, its saying SSL connection not open when we
> go to use inputstreams.
> java.net.SocketException: Socket is not connected
> at java.net.Socket.getInputStream(Socket.java:726) at
> com.ibm.jsse.bs.getInputStream(Unknown Source)
> at
> org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:
> 715)
> at
> org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpCo
> nnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1328)
>
> By way of feedback on the 3.0 API, I'll describe the two places where
> the API is lacking regards our requirements forcing us to do yucky
> overlays. First some context. The crawler must record the response
> headers and response content exactly as it comes back over the wire
> and its supposed to be tenacious.
>
> Regards recording exactly what the server sent us, we overlay
> HttpConnection with a version that wraps the socket input and output
> streams. Here's the diff:
>
> +// HERITRIX import.
> +import org.archive.util.HttpRecorder;
> +
> /**
> * An abstraction of an HTTP {@link InputStream} and {@link
> OutputStream}
> * pair, together with the relevant attributes.
> @@ -676,7 +679,6 @@
> highly interactive environments, such as some client/server
> situations. In such cases, nagling may be turned off
> through
> use of the TCP_NODELAY sockets option." */
> -
> socket.setTcpNoDelay(this.params.getTcpNoDelay());
> socket.setSoTimeout(this.params.getSoTimeout());
>
> @@ -701,8 +703,23 @@
> if (inbuffersize > 2048) {
> inbuffersize = 2048; }
> - inputStream = new
> BufferedInputStream(socket.getInputStream(), inbuffersize);
> - outputStream = new
> BufferedOutputStream(socket.getOutputStream(), outbuffersize);
> + // START HERITRIX Change
> + HttpRecorder httpRecorder =
> HttpRecorder.getHttpRecorder();
> + if (httpRecorder == null) {
> + inputStream = new BufferedInputStream(
> + socket.getInputStream(), inbuffersize);
> + outputStream = new BufferedOutputStream(
> + socket.getOutputStream(), outbuffersize);
> + } else {
> + inputStream = httpRecorder.inputWrap((InputStream)
> + (new BufferedInputStream(socket.getInputStream(),
> + inbuffersize)));
> + outputStream = httpRecorder.outputWrap((OutputStream)
> + (new
> BufferedOutputStream(socket.getOutputStream(),
> + outbuffersize)));
> + }
> + // END HERITRIX change.
> +
>
> The other overlay we make is of HttpParser so we can persist through a
> bad header parse:
>
> /apache/commons/httpclient/HttpParser.java
> src/java/org/apache/commons/httpclient/HttpParser.java ---
> /home/stack/bin/commons-httpclient-3.0-alpha2/src/java/org/apache/
> commons/httpclient/HttpParser.java 2004-09-19
> 13:41:05.000000000 -0700 +++
> src/java/org/apache/commons/httpclient/HttpParser.java 2004-09-29
> 14:23:03.000000000 -0700
> @@ -185,11 +185,21 @@
> // Otherwise we should have normal HTTP header line
> // Parse the header name and value
> int colon = line.indexOf(":");
> + // START HERITRIX Change
> + // Don't throw an exception if can't parse. We want
> to keep
> + // going even though header is bad. Rather, create
> + // pseudo-header.
> if (colon < 0) { - throw new
> ProtocolException("Unable to parse header: " + line); +
> // throw new ProtocolException("Unable to parse header: " ++
> // line);
> - throw new ProtocolException("Unable to parse
> header: " + line); + // throw new
> ProtocolException("Unable to parse header: " ++ //
> line);
> + name = "HttpClient-Bad-Header-Line-Failed-Parse";
> + value = new StringBuffer(line);
> +
> + } else {
> + name = line.substring(0, colon).trim();
> + value = new StringBuffer(line.substring(colon +
> 1).trim()); }
> - name = line.substring(0, colon).trim();
> - value = new StringBuffer(line.substring(colon +
> 1).trim()); + // END HERITRIX change.
> }
>
> I don't see ye ever making the socket streams available via the API.
> I've been following the list long enough to see that exposing these
> streams is a no-no -- and I can appreciate all the work done in the
> software keeping them encapsulated. The second patch might be
> something to consider. Apart from these two cases, the API is most
> amenable.
>
> Thanks for the great software.
> Yours,
> St.Ack
>
> P.S: Here is a submission for the
> http://jakarta.apache.org/commons/httpclient/applications.html page:
>
> Heritrix (http://crawler.archive.org is the Internet Archive's
> (http://www.archive.org) open-source, extensible, web-scale,
> archival-quality
> web crawler project.
>
>
>> Oleg
>>
>>
>>
>> On Tue, 2004-09-28 at 20:37, Adam R. B. Jack wrote:
>>
>>>>> On Mon, 2004-09-20 at 22:50, Oleg Kalnichevski wrote:
>>>>>
>>>>>> As far as I know the following projects rely on HttpClient 2.0 as
>>>>>> a
>>>>>> required or optional dependency
>>>>>>
>>>>>> * Apache Jakarta Slide (http://jakarta.apache.org/slide/)
>>>>>> * Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
>>>>>> * Apache Axis (http://ws.apache.org/axis/)
>>>>>> * Apache XML-RPC (http://ws.apache.org/xmlrpc/)
>>>>>> * Spring Framework (http://www.springframework.org/)
>>>>>> * HtmlUntit (http://htmlunit.sourceforge.net/)
>>>>>> * XINS (http://xins.sourceforge.net/)
>>>>>>
>>> Just stumbled over this mail. Does the "Dependees" list here help
>>> give you
>>> other possibles?
>>>
>>>
>>> http://brutus.apache.org/gump/public/jakarta-commons/commons-
>>> httpclient/details.html
>>>
>>> regards,
>>>
>>> Adam
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>>> commons-httpclient-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> commons-httpclient-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by stack <st...@archive.org>.
Oleg Kalnichevski wrote:
>Thanks, Adam
>
>Should we decide to go on a spamming spree, these may also become
>potential victims ;-)
>
>
>
Let me preempt the spam (smile).
I'm part of the webgroup at the Internet Archive (archive.org). We've
been using httpclient at the heart of our open source crawler Heritrix
(crawler.archive.org) for near on a year now (I've added on the end a
submission for the httpclient applications page). I've just upgraded
HEAD to use 3.0alpha2 and was going to say a few words about the
experience and how its running.
Heads up. The following message is a little long.
The upgrade took way longer than I anticipated, a couple of days rather
than a couple of hours. While some of the time was spent on refactoring
only slightly related to the httpcilent upgrade and testing to see all
httpclient used features still work post upgrade, the bulk of the time
was spent on redoing our auth system to fit the redesigned httpclient
auth system. I had trouble figuring out how things work now in the
absence of example. Our usage is a little out-of-the-ordinary in that we
manage own store of credentials and manage when to load them onto a
httpmethod. Previous, HttpAuthenticator would select the scheme for
me. Now it seems like I have to do it myself using AuthChallengeParser
and then iterate over the returns. In general the new auth system
changes look to be for the best. It just cost time exploring.
Thereafter, the remainder was spent undoing our own custom retry to
instead use a custom HttpMethodRetryHandler that is now part of
httpclient core, study of the new configuration system to ensure correct
usage, undoing old ways of specifying preferences, and exploiting new
preference granularity particularly where it could make the crawler more
robust (UNAMBIGUOUS_STATUS_LINE, STRICT_TRANSFER_ENCODING,
STATUS_LINE_GARBAGE_LIMIT, etc).
With the new lib in place, we pass all of our little suite of selftests
(includes Auth tests of logins and Basic and Digest Auth), and random
broad crawling shows performance as comparable with the only weird
exceptions having to do with timeouts on IBM SSL Sockets. Later I should
have more detailed feedback on performance and robustness.
The IBM SSL socket timeout issues I'm seeing when I get an SSLSocket
with a timeout (I set the timeout by getting a socket with the null arg
constructor then doing an SSLSocket$connect with a timeout). The
exceptions do not happen when I use SUN JVM 1.4.2. These are probably
IBM JVM issues but I'll list them here anyways:
1. The IBM JVM 141 (cxia321411-20030930) NPEs setting the NoTcpDelay.
Is anyone else seeing this?
java.lang.NullPointerException
at com.ibm.jsse.bf.setTcpNoDelay(Unknown Source)
at
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:683)
at
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1328)
2. Using the IBM JVM 142, its saying SSL connection not open when we go
to use inputstreams.
java.net.SocketException: Socket is not connected
at java.net.Socket.getInputStream(Socket.java:726) at
com.ibm.jsse.bs.getInputStream(Unknown Source)
at
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:715)
at
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1328)
By way of feedback on the 3.0 API, I'll describe the two places where
the API is lacking regards our requirements forcing us to do yucky
overlays. First some context. The crawler must record the response
headers and response content exactly as it comes back over the wire and
its supposed to be tenacious.
Regards recording exactly what the server sent us, we overlay
HttpConnection with a version that wraps the socket input and output
streams. Here's the diff:
+// HERITRIX import.
+import org.archive.util.HttpRecorder;
+
/**
* An abstraction of an HTTP {@link InputStream} and {@link OutputStream}
* pair, together with the relevant attributes.
@@ -676,7 +679,6 @@
highly interactive environments, such as some client/server
situations. In such cases, nagling may be turned off through
use of the TCP_NODELAY sockets option." */
-
socket.setTcpNoDelay(this.params.getTcpNoDelay());
socket.setSoTimeout(this.params.getSoTimeout());
@@ -701,8 +703,23 @@
if (inbuffersize > 2048) {
inbuffersize = 2048; }
- inputStream = new
BufferedInputStream(socket.getInputStream(), inbuffersize);
- outputStream = new
BufferedOutputStream(socket.getOutputStream(), outbuffersize);
+ // START HERITRIX Change
+ HttpRecorder httpRecorder = HttpRecorder.getHttpRecorder();
+ if (httpRecorder == null) {
+ inputStream = new BufferedInputStream(
+ socket.getInputStream(), inbuffersize);
+ outputStream = new BufferedOutputStream(
+ socket.getOutputStream(), outbuffersize);
+ } else {
+ inputStream = httpRecorder.inputWrap((InputStream)
+ (new BufferedInputStream(socket.getInputStream(),
+ inbuffersize)));
+ outputStream = httpRecorder.outputWrap((OutputStream)
+ (new BufferedOutputStream(socket.getOutputStream(),
+ outbuffersize)));
+ }
+ // END HERITRIX change.
+
The other overlay we make is of HttpParser so we can persist through a
bad header parse:
/apache/commons/httpclient/HttpParser.java
src/java/org/apache/commons/httpclient/HttpParser.java ---
/home/stack/bin/commons-httpclient-3.0-alpha2/src/java/org/apache/commons/httpclient/HttpParser.java
2004-09-19 13:41:05.000000000 -0700 +++
src/java/org/apache/commons/httpclient/HttpParser.java 2004-09-29
14:23:03.000000000 -0700
@@ -185,11 +185,21 @@
// Otherwise we should have normal HTTP header line
// Parse the header name and value
int colon = line.indexOf(":");
+ // START HERITRIX Change
+ // Don't throw an exception if can't parse. We want to
keep
+ // going even though header is bad. Rather, create
+ // pseudo-header.
if (colon < 0) { - throw new
ProtocolException("Unable to parse header: " + line);
+ // throw new ProtocolException("Unable to parse
header: " ++ // line);
- throw new ProtocolException("Unable to parse
header: " + line); + // throw new
ProtocolException("Unable to parse header: " ++
// line);
+ name = "HttpClient-Bad-Header-Line-Failed-Parse";
+ value = new StringBuffer(line);
+
+ } else {
+ name = line.substring(0, colon).trim();
+ value = new StringBuffer(line.substring(colon +
1).trim()); }
- name = line.substring(0, colon).trim();
- value = new StringBuffer(line.substring(colon +
1).trim()); + // END HERITRIX change.
}
I don't see ye ever making the socket streams available via the API.
I've been following the list long enough to see that exposing these
streams is a no-no -- and I can appreciate all the work done in the
software keeping them encapsulated. The second patch might be something
to consider. Apart from these two cases, the API is most amenable.
Thanks for the great software.
Yours,
St.Ack
P.S: Here is a submission for the
http://jakarta.apache.org/commons/httpclient/applications.html page:
Heritrix (http://crawler.archive.org is the Internet Archive's
(http://www.archive.org) open-source, extensible, web-scale,
archival-quality
web crawler project.
>Oleg
>
>
>
>On Tue, 2004-09-28 at 20:37, Adam R. B. Jack wrote:
>
>
>>>>On Mon, 2004-09-20 at 22:50, Oleg Kalnichevski wrote:
>>>>
>>>>
>>>>>As far as I know the following projects rely on HttpClient 2.0 as a
>>>>>required or optional dependency
>>>>>
>>>>>* Apache Jakarta Slide (http://jakarta.apache.org/slide/)
>>>>>* Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
>>>>>* Apache Axis (http://ws.apache.org/axis/)
>>>>>* Apache XML-RPC (http://ws.apache.org/xmlrpc/)
>>>>>* Spring Framework (http://www.springframework.org/)
>>>>>* HtmlUntit (http://htmlunit.sourceforge.net/)
>>>>>* XINS (http://xins.sourceforge.net/)
>>>>>
>>>>>
>>Just stumbled over this mail. Does the "Dependees" list here help give you
>>other possibles?
>>
>>
>>http://brutus.apache.org/gump/public/jakarta-commons/commons-httpclient/details.html
>>
>>regards,
>>
>>Adam
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: client-certificate authentication
Posted by Oleg Kalnichevski <ol...@apache.org>.
Mark,
We do not have a full-blown tutorial on this subject as SSL
authentication is basically is out of HttpClient scope.
This sample code does, however, have extensive javadocs on the matter.
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/AuthSSLProtocolSocketFactory.java?only_with_tag=HTTPCLIENT_2_0_BRANCH&view=markup
The two other files required to compile AuthSSLProtocolSocketFactory can
found here
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/?only_with_tag=HTTPCLIENT_2_0_BRANCH
Hope this helps
Oleg
On Tue, 2004-09-28 at 23:00, Mark Wilcox wrote:
> Hi,
> Is there any documentation on how to do client-certificate authentication
> with HTTPClient?
>
> I didn't see anything in the SSL docs on the web site or via Google.
>
> Thanks,
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
client-certificate authentication
Posted by Mark Wilcox <ma...@webct.com>.
Hi,
Is there any documentation on how to do client-certificate authentication
with HTTPClient?
I didn't see anything in the SSL docs on the web site or via Google.
Thanks,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by Oleg Kalnichevski <ol...@apache.org>.
Thanks, Adam
Should we decide to go on a spamming spree, these may also become
potential victims ;-)
Oleg
On Tue, 2004-09-28 at 20:37, Adam R. B. Jack wrote:
> > > On Mon, 2004-09-20 at 22:50, Oleg Kalnichevski wrote:
> > > > As far as I know the following projects rely on HttpClient 2.0 as a
> > > > required or optional dependency
> > > >
> > > > * Apache Jakarta Slide (http://jakarta.apache.org/slide/)
> > > > * Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
> > > > * Apache Axis (http://ws.apache.org/axis/)
> > > > * Apache XML-RPC (http://ws.apache.org/xmlrpc/)
> > > > * Spring Framework (http://www.springframework.org/)
> > > > * HtmlUntit (http://htmlunit.sourceforge.net/)
> > > > * XINS (http://xins.sourceforge.net/)
>
> Just stumbled over this mail. Does the "Dependees" list here help give you
> other possibles?
>
>
> http://brutus.apache.org/gump/public/jakarta-commons/commons-httpclient/details.html
>
> regards,
>
> Adam
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by "Adam R. B. Jack" <aj...@apache.org>.
> > On Mon, 2004-09-20 at 22:50, Oleg Kalnichevski wrote:
> > > As far as I know the following projects rely on HttpClient 2.0 as a
> > > required or optional dependency
> > >
> > > * Apache Jakarta Slide (http://jakarta.apache.org/slide/)
> > > * Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
> > > * Apache Axis (http://ws.apache.org/axis/)
> > > * Apache XML-RPC (http://ws.apache.org/xmlrpc/)
> > > * Spring Framework (http://www.springframework.org/)
> > > * HtmlUntit (http://htmlunit.sourceforge.net/)
> > > * XINS (http://xins.sourceforge.net/)
Just stumbled over this mail. Does the "Dependees" list here help give you
other possibles?
http://brutus.apache.org/gump/public/jakarta-commons/commons-httpclient/details.html
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by Michael Becke <be...@u.washington.edu>.
I have no problem with posting to the dev lists for these other
projects. My feeling is that we should keep it friendly and just
encourage people to have a look at 3.0 and then submit their
requests/ideas to httpclient-dev or bugzilla. Once we've done that I
think we'll just have to be happy with the input we've had so far and
move on. There's only so much poking and prodding that we can do.
Mike
On Sep 28, 2004, at 12:09 PM, Oleg Kalnichevski wrote:
> Folks, shall we try to approach members of the projects listed below
> (except Slide) directly? Apparently no one of them is monitoring this
> list.
>
> How does everyone feel about it?
>
> Oleg
>
> On Mon, 2004-09-27 at 20:43, Oleg Kalnichevski wrote:
>> Sadly, no one seems to care. What do we do?
>>
>> Oleg
>>
>>
>> On Mon, 2004-09-20 at 22:50, Oleg Kalnichevski wrote:
>>> As far as I know the following projects rely on HttpClient 2.0 as a
>>> required or optional dependency
>>>
>>> * Apache Jakarta Slide (http://jakarta.apache.org/slide/)
>>> * Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
>>> * Apache Axis (http://ws.apache.org/axis/)
>>> * Apache XML-RPC (http://ws.apache.org/xmlrpc/)
>>> * Spring Framework (http://www.springframework.org/)
>>> * HtmlUntit (http://htmlunit.sourceforge.net/)
>>> * XINS (http://xins.sourceforge.net/)
>>>
>>> I just wonder if any of the projects' committers are currently
>>> subscribed to or monitor this mail list?
>>>
>>> We would love to know if there are any plans to evaluate HttpClient
>>> 3.0,
>>> or any migration plans already. What can we do to make the
>>> transition,
>>> if planned, easier?
>>>
>>> Oleg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>>> commons-httpclient-dev-help@jakarta.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> commons-httpclient-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by Oleg Kalnichevski <ol...@apache.org>.
Folks, shall we try to approach members of the projects listed below
(except Slide) directly? Apparently no one of them is monitoring this
list.
How does everyone feel about it?
Oleg
On Mon, 2004-09-27 at 20:43, Oleg Kalnichevski wrote:
> Sadly, no one seems to care. What do we do?
>
> Oleg
>
>
> On Mon, 2004-09-20 at 22:50, Oleg Kalnichevski wrote:
> > As far as I know the following projects rely on HttpClient 2.0 as a
> > required or optional dependency
> >
> > * Apache Jakarta Slide (http://jakarta.apache.org/slide/)
> > * Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
> > * Apache Axis (http://ws.apache.org/axis/)
> > * Apache XML-RPC (http://ws.apache.org/xmlrpc/)
> > * Spring Framework (http://www.springframework.org/)
> > * HtmlUntit (http://htmlunit.sourceforge.net/)
> > * XINS (http://xins.sourceforge.net/)
> >
> > I just wonder if any of the projects' committers are currently
> > subscribed to or monitor this mail list?
> >
> > We would love to know if there are any plans to evaluate HttpClient 3.0,
> > or any migration plans already. What can we do to make the transition,
> > if planned, easier?
> >
> > Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by Oleg Kalnichevski <ol...@apache.org>.
Sadly, no one seems to care. What do we do?
Oleg
On Mon, 2004-09-20 at 22:50, Oleg Kalnichevski wrote:
> As far as I know the following projects rely on HttpClient 2.0 as a
> required or optional dependency
>
> * Apache Jakarta Slide (http://jakarta.apache.org/slide/)
> * Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
> * Apache Axis (http://ws.apache.org/axis/)
> * Apache XML-RPC (http://ws.apache.org/xmlrpc/)
> * Spring Framework (http://www.springframework.org/)
> * HtmlUntit (http://htmlunit.sourceforge.net/)
> * XINS (http://xins.sourceforge.net/)
>
> I just wonder if any of the projects' committers are currently
> subscribed to or monitor this mail list?
>
> We would love to know if there are any plans to evaluate HttpClient 3.0,
> or any migration plans already. What can we do to make the transition,
> if planned, easier?
>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by Oleg Kalnichevski <ol...@apache.org>.
Eric,
The intention is to keep HttpClient 3.0 compile-compatible with
HttpClient 2.x (except for all that ugly stuff that has been deprecated
in 2.0). Feel free to submit a patch for the HttpException class.
Keep us posted on the progress
Cheers,
Oleg
On Wed, 2004-09-29 at 21:10, Eric Johnson wrote:
> Some feedback, finally.
>
> I attempted to compile the "client" tools of the slide project with the
> HttpClient 3.0 alpha release.
>
> You'll probably not be surprised to hear that it didn't compile. It
> turns out that a few missing functions in the HttpException class cause
> the compile failures. I added those few functions in to my local copy,
> and everything compiled.
>
> The code that I have that runs on top of those libraries also compiled
> without any further changes.
>
> I didn't actually run any of the code, though. I suspect that the
> changes in exception handling would make any such endeavors more work
> than I want to tackle right now.
>
> I think my next step is to ask that the client libraries of the Slide
> project start using different version numbers from the server side
> tools, and then suggest a 3.0 release of the slide client libraries that
> will use the 3.0 HttpClient. Since getting it to compile was easy, I
> suspect that the rest of it will be fairly straightforward too.
>
> -Eric.
>
> Oleg Kalnichevski wrote:
>
> >As far as I know the following projects rely on HttpClient 2.0 as a
> >required or optional dependency
> >
> >* Apache Jakarta Slide (http://jakarta.apache.org/slide/)
> >* Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
> >* Apache Axis (http://ws.apache.org/axis/)
> >* Apache XML-RPC (http://ws.apache.org/xmlrpc/)
> >* Spring Framework (http://www.springframework.org/)
> >* HtmlUntit (http://htmlunit.sourceforge.net/)
> >* XINS (http://xins.sourceforge.net/)
> >
> >I just wonder if any of the projects' committers are currently
> >subscribed to or monitor this mail list?
> >
> >We would love to know if there are any plans to evaluate HttpClient 3.0,
> >or any migration plans already. What can we do to make the transition,
> >if planned, easier?
> >
> >Oleg
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: ATTN Open-source projects using HttpClient
Posted by Eric Johnson <er...@tibco.com>.
Some feedback, finally.
I attempted to compile the "client" tools of the slide project with the
HttpClient 3.0 alpha release.
You'll probably not be surprised to hear that it didn't compile. It
turns out that a few missing functions in the HttpException class cause
the compile failures. I added those few functions in to my local copy,
and everything compiled.
The code that I have that runs on top of those libraries also compiled
without any further changes.
I didn't actually run any of the code, though. I suspect that the
changes in exception handling would make any such endeavors more work
than I want to tackle right now.
I think my next step is to ask that the client libraries of the Slide
project start using different version numbers from the server side
tools, and then suggest a 3.0 release of the slide client libraries that
will use the 3.0 HttpClient. Since getting it to compile was easy, I
suspect that the rest of it will be fairly straightforward too.
-Eric.
Oleg Kalnichevski wrote:
>As far as I know the following projects rely on HttpClient 2.0 as a
>required or optional dependency
>
>* Apache Jakarta Slide (http://jakarta.apache.org/slide/)
>* Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
>* Apache Axis (http://ws.apache.org/axis/)
>* Apache XML-RPC (http://ws.apache.org/xmlrpc/)
>* Spring Framework (http://www.springframework.org/)
>* HtmlUntit (http://htmlunit.sourceforge.net/)
>* XINS (http://xins.sourceforge.net/)
>
>I just wonder if any of the projects' committers are currently
>subscribed to or monitor this mail list?
>
>We would love to know if there are any plans to evaluate HttpClient 3.0,
>or any migration plans already. What can we do to make the transition,
>if planned, easier?
>
>Oleg
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org