Hi Phil! :) honestly I didn't understand which are the use cases when a pool needs to be reconfigured, that's why I've always used the pool in "configure and use" modality and Seb's suggestion sounded good to me. OTOH I didn't modify any single code line before hearing your thoughts since you know much more than me. If pool's property are mutable, so I need to add the setters, make them final otherwise :P Just let me know! Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Oct 12, 2010 at 5:03 PM, 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. > > 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
