On Fri, Jul 24, 2009 at 03:01:34PM +0100, sebb wrote: > On 24/07/2009, Oleg Kalnichevski <[email protected]> wrote: > > On Fri, Jul 24, 2009 at 01:59:23PM +0100, sebb wrote: > > > On 24/07/2009, Oleg Kalnichevski <[email protected]> wrote: > > > > On Fri, Jul 24, 2009 at 01:07:35AM +0100, sebb wrote: > > > > > Pressed send too soon: > > > > > > > > > > SSLSocketFactory is not inherently thread-safe, because of the > > > > > [gs]etHostNameVerifier() methods. > > > > > Is there a need to change the HostNameVerifier after construction, > > or > > > > > could the verifier be provided to the ctor? Alternatively, perhaps > > the > > > > > field could be made volatile? > > > > > > > > > > > > > > > > > > > > > > I see no good reason for changing hostname verifier after > > construction. Feel free to make the variable final and deprecate the setter. > > > > > > > > > > Huh? There cannot be a setter if the field is final ... > > > > > > > > > The setter does not necessarily have to mutate any variable. It can simply > > be > > left empty. Feel free to throw a runtime exception > > (UnsupportedOperationException for instance) if that makes you more > > comfortable. > > > > OK, I see. Keep the setter method for API compatibility, but disable > (and deprecate) it. > > However, that would mean that existing code would only discover the > problem at run-time, whereas removing the method would cause the > change to be detected at compile-time. > > In both cases, client code will need to be changed. > > I would rather find out the problem at compile-time... >
Same here. In my opinion full binary compatibility without full behavioral compatibility is completely and utterly pointless. I rather have things break on me at compile time than at runtime. But for some reason behavioral incompatibility is often seen as less severe as binary incompatibility. There is no point in trying to be a better catholic than Pope of Rome. Oleg > > Oleg > > > > > > > > > If the field is made final, the only solution is to add the verifier > > > to all the constructors. > > > This means adding some new constructors with the extra field. > > > > > > Which I am happy to do, but is a bit messy now > > > > > > == > > > > > > If the class is constructed and the setHNV() method is called just > > > once, then the instance can be safely passed to a newly created > > > thread, because Thread.start() acts as a common synch. lock between > > > the two threads. > > > > > > However, if the instance is passed to an existing thread, there may be > > > no common synch. lock involved, and the value of any non-final fields > > > may not be published correctly. > > > > > > I'm not sure how the class is intended to be used, so I'm not sure if > > > this is a reasonable approach for the class. > > > > > > > Oleg > > > > > > > > > > > > > > > > > > > > > > On 23/07/2009, sebb <[email protected]> wrote: > > > > > > On 15/07/2009, Oleg Kalnichevski <[email protected]> wrote: > > > > > > > Folks > > > > > > > > > > > > > > Please test your applications against 4.0-rc2 and report bugs > > if found. > > > > > > > > > > > > > > There have been three fixes since 4.0-rc1 > > > > > > > > > > > > > > * [HTTPCLIENT-860] HttpClient no longer converts redirects of > > PUT/POST > > > > > > > to GET for status codes 301, 302, 307, as required by the > > HTTP spec. > > > > > > > > > > > > > > * [HTTPCLIENT-859] CookieIdentityComparator now takes path > > attribute > > > > > > > into consideration when comparing cookies. > > > > > > > > > > > > > > * HttpClient will no longer send expired cookies back to the > > origin > > > > > > > server. > > > > > > > > > > > > > > Please also find a few minutes to review the release packages. > > > > > > > > > > > > > > Packages: > > > > > > > http://people.apache.org/~olegk/httpclient-4.0-rc2/ > > > > > > > > > > > > > > > > > > I've started looking at thread-safety, beginning with > > > > > > ThreadSafeClientConnManager. > > > > > > That sems to be thread-safe, however one of the fields contains > > ConnPoolByRoute. > > > > > > This has non-final protected fields: > > > > > > - freeConnections > > > > > > - waitingThreads > > > > > > which are created in the constructor; I think these should be > > made final. > > > > > > > > > > > > > > > > > > The Interface RefQueueHandler is marked as deprecated, and only > > seems > > > > > > to be used in AbstractConnPool and RefQueueWorker - could these > > be > > > > > > deleted? > > > > > > > > > > > > > > > > > > > Release notes: > > > > > > > > > http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/RELEASE_NOTES.txt > > > > > > > > > > > > > > Oleg > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > 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] > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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] > > > > > > > --------------------------------------------------------------------- > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
