On 15/02/2009, sebb <[email protected]> wrote: > On 15/02/2009, Oleg Kalnichevski <[email protected]> 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: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
