hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Make BasicHttpProcessor Lists final?
Date Sun, 15 Feb 2009 14:44:31 GMT
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


Mime
View raw message