Mailing-List: contact httpclient-users-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-users@hc.apache.org>
Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates
 209.85.219.208 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=Nsei2j2AFJBUVoqkB0hgHXjzzTRp0jmIWhe4tJMnryHSpViTCjFJMIS9FPvnySsVPv
         6jHgALM10m4kezpSxmTzhqUMnVax8F5GSD7/oWzZqlucjJBECPMG70U8eKm3g6NDg3Mg
         hcGqDAFCuFyv/9nwjhXvij01BJYz5F2tYP6gE=
MIME-Version: 1.0
In-Reply-To: <20090724142856.GA32703@ok2cons2.nine.ch>
References: <4A5E2B47.90001@apache.org>
	 <25aac9fc0907231553l5effa6dlc996428af7696f32@mail.gmail.com>
	 <25aac9fc0907231707m7bda1b15vc475dbb7ed387e51@mail.gmail.com>
	 <20090724093059.GB30976@ok2cons2.nine.ch>
	 <25aac9fc0907240559o403ce43em565e8620a4876a1c@mail.gmail.com>
	 <20090724132529.GA17015@ok2cons2.nine.ch>
	 <25aac9fc0907240701h646634efgc14d217ade47ae24@mail.gmail.com>
	 <20090724142856.GA32703@ok2cons2.nine.ch>
Date: Sun, 26 Jul 2009 16:27:42 +0100
Message-ID: <25aac9fc0907260827n1a08cd2fpd0eecba6f21e7a51@mail.gmail.com>
Subject: Re: [HttpClient] HttpClient 4.0-rc2
From: sebb <sebbaz@gmail.com>
To: HttpClient User Discussion <httpclient-users@hc.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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