Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 209.85.219.21 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=sru4JGPmzsQb3lJXCiWN5CTQMDu0ce8Z7wXBoUGwfwGo2AxE2dJbCyQxotL7J3kQx4
         YMgg+E3EYZpGH/Fea7DyBzOYxBHJ6vSHQwdLVqeXprm9nCjRyNvwJAGroPFCcrCMG2c2
         983d04JvQXhwpBoRIpoXa0b8qTMZqEcYzPO6I=
MIME-Version: 1.0
In-Reply-To: <25aac9fc0902150618qd46cde5l102b00b7667fbad9@mail.gmail.com>
References: <25aac9fc0902150519h1199f8cdt1390135833357695@mail.gmail.com>
	 <49981B8E.1080600@apache.org>
	 <25aac9fc0902150618qd46cde5l102b00b7667fbad9@mail.gmail.com>
Date: Sun, 15 Feb 2009 14:44:31 +0000
Message-ID: <25aac9fc0902150644y100bbd06j50f0a150a207a716@mail.gmail.com>
Subject: Re: Make BasicHttpProcessor Lists final?
From: sebb <sebbaz@gmail.com>
To: HttpComponents Project <dev@hc.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 15/02/2009, sebb <sebbaz@gmail.com> wrote:
> On 15/02/2009, Oleg Kalnichevski <olegk@apache.org> wrote:
>  > sebb wrote:
>  >
>  > > The BasicHttpProcessor has two Lists which are currently created on
>  > demand.
>  > >
>  > > This results in a lot of checking to see if the lists exist.
>  > >
>  > > Seems to me it would be better to always create the lists, and make them
>  > final.
>  > > The class could be considerably simplified if this were done, and it
>  > > would help with thread-safety.
>  > >
>  > > Also, do the lists need to be protected, or could they be private?
>  > >
>  > > At least if they are made final, subclasses cannot mess with them as
>  > much...
>  > >
>  > >
>  >
>  >  Makes sense.
>
>
> OK, will do.

I've committed a fix.

I'm not entirely sure about the behaviour of copyInterceptors() -
previously it would only update the target if the source was non-null.
I've changed this to check for size() > 0.

However, this means that the target may not be the same as the source
- if the source has an empty List, the target List is left untouched.

As far as I can tell, this is the same behaviour as before, but was
that behaviour correct?

It won't affect existing calls to the routine since they always pass
in a newly initialised target, whose lists will be empty. But if the
(protected) method is used directly, the behaviour may not be what is
suggested by the method name.

>
>  >  There is no good reason for those lists to be protected but reducing the
>  > visibility of those variables would may break binary compatibility with
>  > existing applications (however unlikely). Let's leave them protected.
>
>
> Seems very unlikely, as the class is final. But again that helps protect them.
>
>
>  >  Oleg
>  >
>  >
>  > > S
>  > >
>  > >
>  > ---------------------------------------------------------------------
>  > > 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