On 24/07/2009, Oleg Kalnichevski <[email protected]> wrote: > 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.
OK, but what is the way forward? Is it OK to break binary compatibility here? > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
