commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [pool] Reusing Config
Date Thu, 28 Oct 2010 15:14:49 GMT
On 28 October 2010 15:16, Simone Tripodi <simone.tripodi@gmail.com> wrote:
> Hi again James, all,
> please review my last commit[1], I refactored the Config and related
> (Keyed)StackObjectPool(Factory), I tried to implements the concepts
> we've been discussing in this thread.

The public StackObjectPoolConfig ctor repeats the settings available
in the nested Builder.
I'm not sure I see the point of having both. Or perhaps the ctor is
supposed to be private?
Also, I don't like the way the ctor resets the parameters if they are
out of range, especially as this is not documented.

==

The StackObjectPool ctor calls the overridable method
reconfigure(StackObjectPoolConfig) which is not safe when subclassing.
Easily fixed by having a private method with the shared code.

Also, reconfigure() updates maxSleeping, but is not synchronized, so
may not publish maxSleeping correctly.

Similar considerations apply to the other classes.

> If this fits to our vision, I can follow applying the refactor to
> Generic(Keyed)ObjectPool(Factory).
> Many thanks in advance!!!
> All the best,
> Simo
>
> [1] http://svn.apache.org/viewvc?rev=1028302&view=rev
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Thu, Oct 28, 2010 at 2:46 PM, Simone Tripodi
> <simone.tripodi@gmail.com> wrote:
>> Hi James,
>> thanks, understood. I take in charge yet another cycle of refactoring,
>> I'll ping you all when in trouble about something :)
>> Have a nice day and thanks for the feedbacks!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Thu, Oct 28, 2010 at 2:12 PM, James Carman
>> <james@carmanconsulting.com> wrote:
>>> On Thu, Oct 28, 2010 at 6:50 AM, Simone Tripodi
>>> <simone.tripodi@gmail.com> wrote:
>>>> That's why I wouldn't follow the option #2; but please, explain me
>>>> which are the side effects of that design, so I can avoid to repeat
>>>> the same mistake in the future.
>>>>
>>>
>>> If you make the config objects immutable, you can just keep the config
>>> references around and skip the copying in the reconfigure() method.  I
>>> don't think it would be difficult to implement things this way.  We
>>> don't want to let the JMX stuff dictate our API too much.  The JMX
>>> stuff can be less "elegant" for sure.  Consider it to be just a UI
>>> layer on top of our stuff.
>>>
>>> ---------------------------------------------------------------------
>>> 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