Adrian et al, Here's my take for what it is worth.
One of the greatest problem with HttpClient has always been the fact that we tried to cover very different use patterns and application types using the same monolithic API. As a result the 2.0 and 3.0 API was still too difficult for those "get me that damn file" type of users and at the same time not flexible enough for developing customized HTTP services. The releaseConnection method was clearly an attempt to simplify the connection management for ordinary users at the expense of flexibility provided for the power users. The good news is that this is no longer an issue. Since we have split monolithic HttpClient into a number of abstraction layers one can simply pick only those bits and pieces that suit their type of application best. For instance, HttpCommons already provides everything that one may need to run simple client and server side services without actually enforcing any design choices for those application aspects that do not directly relate to the HTTP protocol. http://svn.apache.org/viewcvs.cgi/jakarta/httpclient/trunk/http-common/src/examples/org/apache/http/examples/ElementalHttpGet.java http://svn.apache.org/viewcvs.cgi/jakarta/httpclient/trunk/http-common/src/examples/org/apache/http/examples/ElementalHttpEchoServer.java For instance, HttpCommon do not make any provisions to manage HTTP connections. The connection management can be introduced at the level above HttpCommons with very little code. The Coyote HttpConnector I am currently working on can be used as an example: http://svn.apache.org/viewcvs.cgi/jakarta/httpclient/trunk/coyote-httpconnector/src/java/org/apache/http/coyote/ So, the evil (TM) plan is to make releaseConnection irrelevant. We still should seriously consider providing some connection management capabilities in the HttpClient layer that sits on top of HttpCommons, where releaseConnection method may exist in some form or shape. For all those who needs more flexibility that HttpClient is able to provide there are HttpCommons (basic HTTP components) + HttpAuth (the authentication framework) + HttpCookie (the HTTP state management framework) + HttpConn (the connection management framework) to pick components from and roll out their own HTTP client / proxy / server. Oleg On Thu, Aug 11, 2005 at 08:39:07AM +1000, Adrian Sutton wrote: > Hi all, > We've just re-architected our HTTP layer to be able to switch between > HttpClient and the standard JRE classes as with JRE 1.5 Sun's classes > now do NTLM authentication without requiring the user to be prompted > (but in older JRE's it can't do NTLM at all and HttpClient provides a > bunch of other benefits as well). > > The biggest problem we have (and a common cause of problems for > others on this list) is needing to call releaseConnection all the > time. If you are reading the entire response and dealing with it in > one place this is easy to take care of but if you ever need to open a > HTTP connection and then pass off the input stream to various other > parts of the application, this becomes a pain to manage. > > With all the redesigning of HttpClient that's going on, what options > do we have for removing the need for user managed calls to > releaseConnection? We already release the connection automatically > if the entire response stream is read and I think if the input stream > is closed as well - in what situations is this not enough? > > * IOException or other exception while reading from the stream. Our > input stream wrapper could catch this and release the connection then > rethrow the exception. > > * Situations where the response from the server is discarded. This > is most common with error responses from servers like 404s etc but > can happen when the start of the response indicates in some software > specific manner that the rest of the content is irrelevant (eg: an > XML declaration that indicates that the file's version is 2.0 and not > supported by the parser). I'm not sure how to deal with this case > though requiring the user to close the input stream would match how > input streams are normally used, avoid having to read the entire > response and release the connection (the connection of course > couldn't be reused by that's probably a fair trade off given the > saving in not having to download the content). > > What other situations are there that would need to be handled? This > always seemed like a straight out required part of the architecture > but it is surprisingly annoying when you try to integrate HttpClient > into an application without having it pervade the entire codebase. > > Am I crazy? Thoughts? > > Regards, > > Adrian Sutton. > > > > > > --------------------------------------------------------------------- > 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]
