hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: BasicHttpRequest not thread-safe but can be easily made so
Date Mon, 02 Feb 2009 21:47:09 GMT
On 02/02/2009, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Mon, 2009-02-02 at 21:03 +0000, sebb wrote:
>  > On 02/02/2009, Oleg Kalnichevski <olegk@apache.org> wrote:
>  > > sebb wrote:
>  > >
>  > > > BasicHttpRequest currently has a non-final field "requestLine".
>  > > >
>  > > > This could be made final, and the check/update of the field in
>  > > > getRequestLine() removed, as the field cannot be null.
>  > > >
>  > > > S///
>  > > >
>  > > >
>  > >
>  > >  Hi Sebastian,
>  > >
>  > >  The reason for this variable being non-final is to make it possible to
>  > > mutate HTTP protocol version of an existing BasicHttpRequest through the
>  > > HttpParams collection associated with the object.
>  >
>  > However, there is actually no way to change the private variable -
>  > there is only a getter, and no setter - so other classes cannot change
>  > it.
>  >
>
>
> True. But its initialization is deferred until the #getRequestLine()
>  method is called for the first time.

Duh! - sorry, I missed that the construction of the object fetches the
version, which of course can be changed after the original object was
created. Finally I understand it (I hope).

But that applies only if the following constructor is used:

BasicHttpRequest(final String method, final String uri)

The other two constructors set it non-null anyway.

>  Besides, even if the variable was final, the class would still be
>  threading unsafe, as its sub-class (AbstractHttpMessage) is not.

I think you mean super-class, but agreed, it does not make the class
thread-safe.

I withdraw the suggested fix, but I think some documentation is needed
to explain why the field is not initialised in the constructor.

>
>  Oleg
>
>
>
>  > > It is basically a hangover
>  > > from the 3.x days. I do not mind changing the behavior and making the
>  > > variable final.
>  >
>  > Great!
>  >
>  > Though in fact it won't change the behaviour, as mentioned above.
>  >
>  > Sebb
>  >
>
> > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>  > For additional commands, e-mail: dev-help@hc.apache.org
>  >
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>  For additional commands, e-mail: dev-help@hc.apache.org
>
>

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


Mime
View raw message