Hi Seb! :)
Of course, thanks for the suggestion!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Sat, Oct 16, 2010 at 2:51 PM, sebb <seb...@gmail.com> wrote:
> On 16 October 2010 13:10, Simone Tripodi <simone.trip...@gmail.com> wrote:
>> Thanks for the feedbacks Seb!!!
>> what about if I start implementing a proposal and then we
>> progressively refine the design?
>
> Fine by me.
>
> But it might be better to look at how the Tomcat JDBC pool
> implementation might be of use before polishing the current code much
> further.
>
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Sat, Oct 16, 2010 at 1:46 PM, sebb <seb...@gmail.com> wrote:
>>> On 16 October 2010 06:18, Simone Tripodi <simone.trip...@gmail.com> wrote:
>>>> yes, understood and agreed.
>>>> BTW I still find redundant that the same field, used with the same
>>>> semantic, is present in Config,Pool and Factory, my proposal was about
>>>> keeping the Config only - immutable fields can be declared there - and
>>>> remove config parameters from Factory/Pool, that will require a Config
>>>> or use the default one.
>>>
>>> I'd be happy with using config for all parameters.
>>>
>>> If one did not want to have multiple config constructors for them,
>>> then immutable fields could be extracted from the config by the
>>> Factory (etc.) constructors.
>>> The Factory class would then use its local final copy of the immutable
>>> field, and subsequent changes to the config would be ignored.
>>>
>>> This would be fairly easy to implement, but the different treatment of
>>> some config parameters would need to be documented.
>>>
>>>> Otherwise any suggestion is much more than welcome, it would be a
>>>> shame IMHO not improving the design.
>>>> Thanks for discussing about this topic, have a nice day,
>>>> Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://www.99soft.org/
>>>>
>>>>
>>>>
>>>> On Sat, Oct 16, 2010 at 2:25 AM, sebb <seb...@gmail.com> wrote:
>>>>> On 15 October 2010 17:01, Simone Tripodi <simone.trip...@gmail.com> wrote:
>>>>>> Hi all guys,
>>>>>> there are Generic(Keyed)ObjectPool(Factory) that (in pairs, Pool and
>>>>>> related factory) share the same kind of information, replicated in the
>>>>>> related Config class.
>>>>>>
>>>>>> I wonder if we can improve that design and remove that information
>>>>>> redundancy: I propose to keep the Config classes only, put them not as
>>>>>> inner class, in order to remove the circular dependency between
>>>>>> factory/pool and remove also the not so comfortable (at least for me)
>>>>>> n-arguments constructors.
>>>>>> So, the GenericObjectPool, instead of having all these constructors,
>>>>>> could work only with:
>>>>>>
>>>>>> public GenericObjectPool(PoolableObjectFactory<T> factory) {
>>>>>>    this(factory, new Config());
>>>>>> }
>>>>>>
>>>>>> public GenericObjectPool(PoolableObjectFactory<T> factory, Config 
>>>>>> config) {
>>>>>>    this.factory = factory;
>>>>>>    this.config = config;
>>>>>> }
>>>>>>
>>>>>> both factory and config can be final; if users need to reconfigure the
>>>>>> pool at runtime, invoke the setter and modify the interested value
>>>>>>
>>>>>> pool.getConfig().setWhenExhaustedAction(WhenExhaustedAction.GROW);
>>>>>>
>>>>>> I'd extend later the same approach also to other Pools... WDYT?
>>>>>
>>>>> The advantage of using ctor parameters is that they can be saved in a
>>>>> final field.
>>>>> The config approach is OK for parameters that need to remain mutable,
>>>>> but can impose additional synch. requirements for settings that must
>>>>> not be changed during the life of the pool.
>>>>>
>>>>> For example, I suspect LIFO should be immutable, and should therefore be 
>>>>> final.
>>>>>
>>>>>> Many thanks in advance,
>>>>>> Simo
>>>>>>
>>>>>> 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

Reply via email to