Yes
On Oct 12, 2010, at 12:17 PM, Simone Tripodi <simone.trip...@gmail.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
