Date: 2005-01-15T09:34:52 Editor: OlegKalnichevski Wiki: Jakarta-HttpClient Wiki Page: HttpClientApiRedesign URL: http://wiki.apache.org/jakarta-httpclient/HttpClientApiRedesign
no comment Change Log: ------------------------------------------------------------------------------ @@ -17,10 +17,8 @@ depends on - * Java 1.4 (* pending user poll and committer vote) - * commons-logging (* avoid this dependency if technically feasible) - -The rationale behind trying to avoid dependency on a logging framework is to keep the component reusable by projects that have already standardized on a certain logging framework. + * Java 1.4 (* see notes) + * commons-logging (** see notes) provides @@ -95,9 +93,8 @@ depends on - * Java 1.4 (* pending user poll and committer vote) - * commons-logging (* avoid this dependency if technically feasible) - * http-common (* avoid this dependency if technically feasible) + * Java 1.4 (* see notes) + * commons-logging (** see notes) The rationale behind trying to avoid dependency on a logging framework is to keep the component reusable by projects that have already standardized on a certain logging framework. @@ -128,8 +125,8 @@ depends on - * Java 1.4 (* pending user poll and committer vote) - * commons-logging (* avoid this dependency if technically feasible) + * Java 1.4 (* see notes) + * commons-logging (** see notes) * commons-codec * http-common @@ -157,8 +154,8 @@ depends on - * Java 1.4 (* pending user poll and committer vote) - * commons-logging (* avoid this dependency if technically feasible) + * Java 1.4 (* see notes) + * commons-logging (** see notes) * http-common * commons-pool (really needed? vote?) @@ -182,8 +179,8 @@ depends on - * Java 1.4 (* pending user poll and committer vote) - * commons-logging (* avoid this dependency if technically feasible) + * Java 1.4 (* see notes) + * commons-logging (** see notes) * http-common * http-conn @@ -221,10 +218,9 @@ depends on - * Java 1.4 (* pending user poll and committer vote) - * commons-logging (* consider UGLI as an alternative) + * Java 1.4 (* see notes) + * commons-logging (** see notes) * commons-codec - * commons-pool (really needed? vote?) * http-common * http-cookie * http-auth @@ -254,12 +250,13 @@ depends on - * Java 1.4 (* pending user poll and committer vote) + * Java 1.4 (* see notes) * commons-logging * commons-codec * http-common * http-cookie * http-auth + * http-conn * http-client Provided there are any volunteers to maintain it. @@ -270,8 +267,8 @@ depends on - * Java 1.4 (* pending user poll and committer vote) - * commons-logging (* consider UGLI as an alternative) + * Java 1.4 (* see notes) + * commons-logging (** see notes) * commons-codec * http-common * http-cookie @@ -286,8 +283,8 @@ depends on - * Java 1.4 (* pending user poll and committer vote) - * commons-logging (* consider UGLI as an alternative) + * Java 1.4 (* see notes) + * commons-logging (** see notes) * commons-codec * http-common * http-cookie @@ -300,6 +297,16 @@ This chapter is for detailed explanatory notes that would mess up the component descriptions if written inline. +== * JVM requirement == + +Pending user poll and committer vote + +== ** Logging toolkit == + +Avoid dependency on a logging toolkit whenever technically feasible. The rationale behind trying to avoid dependency on a logging framework is to keep the component reusable by projects that have already standardized on a certain logging framework. + +Consider using Apache Logging UGLI as an alternative to Jakarta Commons Logging. [http://issues.apache.org/bugzilla/show_bug.cgi?id=32937 PR# 32937] + == Pipelining == The idea behind the {{{ PipeliningAsyncLink }}} in '''http-async''' is to start up a pair of background threads for each connection that is used. One thread sends requests, the other receives the responses on the connection. When a request is sent over the pipelining link, the class checks whether there is a connection to that host. If so, it delegates the request to the corresponding sender thread. Otherwise, it queues the request in a shared queue. @@ -309,3 +316,5 @@ Connections are released when a receiving thread detects that there are no more responses pending on the connection, or when a communication error occurs. When there are no more requests, connection release can be delayed. In case of a communication error, requests that are queued on the sending thread are moved to the shared queue, where they can be picked up again. The error itself is reported to the callback interfaces for all requests already sent over the connection for which no response has been received yet. Premature connection release can be enforced, for example based on the number of requests sent through the pipeline or the time since the pipeline has been created. This prevents clogging of the asynchronous link in cases where the number of target hosts exceeds the maximum number of pipelines. + +[http://issues.apache.org/bugzilla/show_bug.cgi?id=22628 PR #22628] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
