Andrea, Both 2.0 & CVS HEAD nightlies are available <http://jakarta.apache.org/commons/httpclient/downloads.html>.
This may sound a bit harsh, but I _personally_ do not see 2.0 API worthwhile of any further development. As useful as it is HttpClient 2.0 API is fundamentally flawed in many ways. HttpClient 3.0 will resolve many of the known problems <http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/release_notes.txt?rev=1.21&view=markup> and will render 2.0 completely obsolete. Again, this is just my personal (humble) opinion. As long as there's substantial interest in HttpClient 2.0, it will be supported. However, I do think all new development should take place in CVS HEAD. Oleg -----Original Message----- From: Andrea Fabris [mailto:[EMAIL PROTECTED] Sent: Friday, May 07, 2004 12:06 To: Commons HttpClient Project Subject: Re: MultiThreadedConnectionManager based on commons pool On 07/05/2004 10.38, Kalnichevski, Oleg wrote: > Andrea, > > New HttpClient 3.0 API has not been properly documented yet (documentation and test > case coverage will become a top priority right after the 3.0-alpha1 release). The > idle connection management with the multi-threaded connection manager does take a > little bit of explaining. Per default the connection manager does not attempt to > close idle connections as before. It simply provides the user with the means to > handle idle connections the way the user sees fit. There's a new method in the > HttpConnectionManager interface called #closeIdleConnections(long) intended to > advise the connection manager to drop those connections that have been idle for the > specified period of time. This method can be invoked either from the main > communication thread during a period of inactivity or from a dedicated monitor > thread on a regular basis. The helper class IdleConnectionTimeoutThread can be used > to easily set up a simple idle connection monitor. The reason for not running a > dedicated idle con nection monitor per default is to keep HttpClient usable in an EJB container. The EJB spec requires that enterprise beans do no explicit thread management. > > Give the new features another shot. They may still prove not that bad > > I just had the first cursory look at your commons-pool based implementation. It > looks very promising but the code currently requires a few tweaks to be compatible > with 3.0 API. > > > Oleg Well, i thought the patch was for 2.0 branch, not 3.0!!! (i have to admit that i gave only a fast look at the bugzilla reports on the list, 'cause i had a lot of work to do.. ;-) ) In fact i developed the code from the official 2.0 code! However, i'll try to download the source from cvs, and compile it.. i think that the nightly builds are from 2.0 branch, or not? By the way, if you need further information about my code, feel free to ask Cheers Andrea Errore Apertura DB --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *************************************************************************************************** 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
