+1 also on syncronizing the methods, I can take this task in charge. Thanks all, Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Oct 12, 2010 at 6:46 PM, Gary Gregory <ggreg...@seagullsoftware.com> wrote: >> -----Original Message----- >> From: sebb [mailto:seb...@gmail.com] >> Sent: Tuesday, October 12, 2010 09:39 >> To: Commons Developers List >> Subject: Re: [pool] runtime re-configuration >> >> On 12 October 2010 17:13, Phil Steitz <phil.ste...@gmail.com> wrote: >> > On 10/12/10 11:26 AM, sebb wrote: >> >> >> >> On 12 October 2010 16:03, Phil Steitz<phil.ste...@gmail.com> wrote: >> >>> >> >>> On 10/12/10 7:32 AM, Simone Tripodi wrote: >> >>>> >> >>>> Hi Seb, >> >>>> I totally agree, I'm for this solution, BTW I'll wait the Phil's >> >>>> opinion that knows more than me. >> >>>> Thanks! >> >>>> Simo >> >>>> >> >>>> http://people.apache.org/~simonetripodi/ >> >>>> http://www.99soft.org/ >> >>>> >> >>>> >> >>>> >> >>>> On Tue, Oct 12, 2010 at 12:50 PM, sebb<seb...@gmail.com> wrote: >> >>>>> >> >>>>> On 12 October 2010 10:20, Simone Tripodi<simone.trip...@gmail.com> >> >>>>> wrote: >> >>>>>> >> >>>>>> Hi all guys, >> >>>>>> while fixing the deprecated properties in classes like >> >>>>>> StackKeyedObjectPool[1], I noticed this class instance was >> >>>>>> re-configured during the test[2] (see line 126); is the >> >>>>>> "reconfigure-in-runtime" a pool feature we want? I'm asking because >> >>>>>> I've never experienced the pool reconfiguration (I've never had the >> >>>>>> need to do it) so I honestly don't know which is the wished behavior. >> >>>>>> In the scenario we want to keep this feature, since I'm converting >> >>>>>> fields as private, I need to add setters. >> >>>>>> Just let me know!!! Have a nice day, >> >>>>> >> >>>>> AFAIK, the tests that modify the configuration are to be dropped once >> >>>>> the variables are made private. >> >>>>> The idea was not just to make the variables private, but to make them >> >>>>> final as far as possible to improve thread safety. >> >>>>> >> >>>>> Perhaps Phil can confirm this? >> >>> >> >>> The only property that I think we have agreed at this point to make >> >>> immutable is the factory. I am open to talking about making other >> >>> properties immutable, but I think we should get some broader input on >> >>> this >> >>> topic. >> >> >> >> The field in question is _maxSleeping which has already been marked as: >> >> >> >> "@deprecated to be removed in pool 2.0. Use {...@link #getMaxSleeping()}" >> >> >> >> The field is settable by using the appropriate constructor. >> >> >> >> I thought we had decided to make such fields final as part of POOL-169? >> >> >> >> Indeed, it seems it was psteiz who committed r990437 which added the >> >> deprecated comment ...s >> > >> > I meant to deprecate the protected field - meaning that direct access would >> > not be supported in 2.0. I did not mean to imply that the decision had >> > been >> > made that there would be no setter. We need to talk about this general >> > topic. I have a few times had occasion to increase maxActive and make >> > other >> > modifications to pools at runtime. I could personally live without this, >> > but it is a big difference that we should allow the community to weigh in >> > on >> > if we are talking here about all pool properties. >> >> I see. >> >> At least once we have moved to private fields and getters/setters, the >> methods can be made synchronised to provide thread-safe updates and >> publication. >> And of course it's much easier to add debugging to track changes. >> >> +1 to no direct access to mutable fields. > > +1 too to no direct access to mutable fields. > >> >> > Phil >> >> >> >>> Phil >> >>>>> >> >>>>>> Simo >> >>>>>> >> >>>>>> [1] http://s.apache.org/bjw >> >>>>>> [2] http://s.apache.org/qB >> >>>>>> >> >>>>>> http://people.apache.org/~simonetripodi/ >> >>>>>> http://www.99soft.org/ >> >>>>>> >> >>>>>> --------------------------------------------------------------------- >> >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> --------------------------------------------------------------------- >> >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >> >>>>> >> >>>>> >> >>>> >> >>>> --------------------------------------------------------------------- >> >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >>>> For additional commands, e-mail: dev-h...@commons.apache.org >> >>>> >> >>> >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >>> For additional commands, e-mail: dev-h...@commons.apache.org >> >>> >> >>> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
