> -----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
