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. 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]
