commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [pool] runtime re-configuration
Date Tue, 12 Oct 2010 17:30:06 GMT
Yes



On Oct 12, 2010, at 12:17 PM, Simone Tripodi <simone.tripodi@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.steitz@gmail.com> wrote:
>> On 10/12/10 11:26 AM, sebb wrote:
>>> 
>>> On 12 October 2010 16:03, Phil Steitz<phil.steitz@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<sebbaz@gmail.com>    wrote:
>>>>>> 
>>>>>> On 12 October 2010 10:20, Simone Tripodi<simone.tripodi@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-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>> 
>>>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> 
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message