Hi Phil, OK that's clear, according to this policy, just to keep things consistent, also *.Config properties should be accessed only by getters/setters, how does it sound for you? Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Oct 12, 2010 at 6:13 PM, 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. > > 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
