Hi Mohammad Thanks for the feedback. See my comments below:
> 1) The new Params hierarchy is cool. One thing that seems a little strange > is constructs like: > > method.getParams().setSoTimeout(20000); > > Seems a little unintuitive to call a set method after a get, especially > because there is also the setParams() method. In other words, it's not clear > if the above is the preferred method, or maybe: > > Params p = method.getParams(); // should this be new Params(); ?? > p.setX(x); > method.setParams(p); I personally do find this kind of constructs unintuitive, but tastes can certainly differ. The real problem is that HttpClient API uses this kind of approach in several instances agent.getState().setCredentials(...) agent.getHostConfiguration().setHost(...) to name a few. If this approach is to be changed, it should be done consistently across the entire HttpClient API > 2) The deprecated set parameter methods in HttpClient seem to set the > parameters on the connection manager. Why? Shouldn't those be set on the > HttpClientParams (specifically, see setSoTimeout()). I might be just an oversight on my part. I'll look into this > 3) Minor point: We got an IO timeout exception and it didn't have the > underlying cause. I tracked it down to > HttpConnection.WrappedInputStream.handleException: the exception constructor > is not passing in the cause. Trivial to fix, but maybe a short review of the > code is in order to find such instances. Good catch. I'll review the exception handling code in the HttpConnection class and fix what's broken. Thanks a bunch for the input Cheers, Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
