You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2009/07/15 21:17:27 UTC
[HttpClient] HttpClient 4.0-rc2
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/
Release notes:
http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/RELEASE_NOTES.txt
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [HttpClient] HttpClient 4.0-rc2
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, Jul 23, 2009 at 11:53:36PM +0100, sebb wrote:
> On 15/07/2009, Oleg Kalnichevski <ol...@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.
>
+1
>
> The Interface RefQueueHandler is marked as deprecated, and only seems
> to be used in AbstractConnPool and RefQueueWorker - could these be
> deleted?
>
Let's keep them deprecated for a release or two. There is still a possibility
someone might want to look at fixing GC of unused connections.
Oleg
> > 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
Re: [HttpClient] HttpClient 4.0-rc2
Posted by Oleg Kalnichevski <ol...@apache.org>.
sebb wrote:
> On 24/07/2009, Oleg Kalnichevski <ol...@apache.org> wrote:
>> On Fri, Jul 24, 2009 at 03:01:34PM +0100, sebb wrote:
>> > On 24/07/2009, Oleg Kalnichevski <ol...@apache.org> wrote:
>> > > On Fri, Jul 24, 2009 at 01:59:23PM +0100, sebb wrote:
>> > > > On 24/07/2009, Oleg Kalnichevski <ol...@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?
>
Feel free to make any changes you deem necessary. Anything that helps us
get the release rather sooner than later is OK with me.
> Is it OK to break binary compatibility here?
>
I _personally_ would consider making the field final OK (given the fact
we have already made a few similar changes) but removing the public
method less so.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: [HttpClient] HttpClient 4.0-rc2
Posted by sebb <se...@gmail.com>.
On 24/07/2009, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Fri, Jul 24, 2009 at 03:01:34PM +0100, sebb wrote:
> > On 24/07/2009, Oleg Kalnichevski <ol...@apache.org> wrote:
> > > On Fri, Jul 24, 2009 at 01:59:23PM +0100, sebb wrote:
> > > > On 24/07/2009, Oleg Kalnichevski <ol...@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 <se...@gmail.com> wrote:
> > > > > > > On 15/07/2009, Oleg Kalnichevski <ol...@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
Re: [HttpClient] HttpClient 4.0-rc2
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, Jul 24, 2009 at 03:01:34PM +0100, sebb wrote:
> On 24/07/2009, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Fri, Jul 24, 2009 at 01:59:23PM +0100, sebb wrote:
> > > On 24/07/2009, Oleg Kalnichevski <ol...@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.
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 <se...@gmail.com> wrote:
> > > > > > On 15/07/2009, Oleg Kalnichevski <ol...@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
Re: [HttpClient] HttpClient 4.0-rc2
Posted by sebb <se...@gmail.com>.
On 24/07/2009, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Fri, Jul 24, 2009 at 01:59:23PM +0100, sebb wrote:
> > On 24/07/2009, Oleg Kalnichevski <ol...@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...
> 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 <se...@gmail.com> wrote:
> > > > > On 15/07/2009, Oleg Kalnichevski <ol...@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
Re: [HttpClient] HttpClient 4.0-rc2
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, Jul 24, 2009 at 01:59:23PM +0100, sebb wrote:
> On 24/07/2009, Oleg Kalnichevski <ol...@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.
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 <se...@gmail.com> wrote:
> > > > On 15/07/2009, Oleg Kalnichevski <ol...@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
Re: [HttpClient] HttpClient 4.0-rc2
Posted by sebb <se...@gmail.com>.
On 24/07/2009, Oleg Kalnichevski <ol...@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 ...
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 <se...@gmail.com> wrote:
> > > On 15/07/2009, Oleg Kalnichevski <ol...@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
Re: [HttpClient] HttpClient 4.0-rc2
Posted by Oleg Kalnichevski <ol...@apache.org>.
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.
Oleg
>
> On 23/07/2009, sebb <se...@gmail.com> wrote:
> > On 15/07/2009, Oleg Kalnichevski <ol...@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
Re: [HttpClient] HttpClient 4.0-rc2
Posted by sebb <se...@gmail.com>.
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?
On 23/07/2009, sebb <se...@gmail.com> wrote:
> On 15/07/2009, Oleg Kalnichevski <ol...@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
Re: [HttpClient] HttpClient 4.0-rc2
Posted by sebb <se...@gmail.com>.
On 15/07/2009, Oleg Kalnichevski <ol...@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
Re: [HttpClient] HttpClient 4.0-rc2
Posted by ant elder <an...@gmail.com>.
On Wed, Jul 15, 2009 at 8:17 PM, Oleg Kalnichevski<ol...@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/
>
> Release notes:
> http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/RELEASE_NOTES.txt
>
> Oleg
>
Looks good to me. One small thing if you need to redo for some other
reason is the NOTICE file has 1999-2008 and maybe it should be -2009,
though there's been some discussion on other mailing lists about these
dates and it may not matter though AFAICT there hasn't been a clear
conclusion.
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org