hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [HttpClient] HttpClient 4.0-rc2
Date Sun, 26 Jul 2009 15:27:42 GMT
On 24/07/2009, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Fri, Jul 24, 2009 at 03:01:34PM +0100, sebb wrote:
>  > On 24/07/2009, Oleg Kalnichevski <olegk@apache.org> wrote:
>  > > On Fri, Jul 24, 2009 at 01:59:23PM +0100, sebb wrote:
>  > >  > On 24/07/2009, Oleg Kalnichevski <olegk@apache.org> 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 <sebbaz@gmail.com> wrote:
>  > >  > >  > > On 15/07/2009, Oleg Kalnichevski <olegk@apache.org>
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:
>  > >  > >  > >  > httpclient-users-unsubscribe@hc.apache.org
>  > >  > >  > >  >  For additional commands, e-mail:
>  > >  > >  > >  > httpclient-users-help@hc.apache.org
>  > >  > >  > >  >
>  > >  > >  > >  >
>  > >  > >  > >
>  > >  > >  >
>  > >  > >  > ---------------------------------------------------------------------
>  > >  > >  > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>  > >  > >  > For additional commands, e-mail: httpclient-users-help@hc.apache.org
>  > >  > >  >
>  > >  > >
>  > >  > >  ---------------------------------------------------------------------
>  > >  > >  To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>  > >  > >  For additional commands, e-mail: httpclient-users-help@hc.apache.org
>  > >  > >
>  > >  > >
>  > >  >
>  > >  > ---------------------------------------------------------------------
>  > >  > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>  > >  > For additional commands, e-mail: httpclient-users-help@hc.apache.org
>  > >  >
>  > >
>  > >  ---------------------------------------------------------------------
>  > >  To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>  > >  For additional commands, e-mail: httpclient-users-help@hc.apache.org
>  > >
>  > >
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>  > For additional commands, e-mail: httpclient-users-help@hc.apache.org
>  >
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>  For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org


Mime
View raw message