sure, I always wait for feedbacks before coding :P Cool expression
"Rambo through the code", that was the first time I read it and made
me laugh :D
All the best,
Simo

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



On Wed, Oct 20, 2010 at 9:17 PM, Gary Gregory
<ggreg...@seagullsoftware.com> wrote:
> It seems to me there is a reason the code is the way it is so I'd really like 
> to hear thoughts from some of the original authors before we go and Rambo 
> through the code ;)
>
> Gary
>
> On Oct 20, 2010, at 12:13, "Simone Tripodi" <simone.trip...@gmail.com> wrote:
>
>> Hi Gary,
>> yes that's me that raised the question[1] and discussed a little with
>> Seb. What blocked me was the JMX support proposal since I'm not
>> familiar with that technology, so I was consulting documentation to
>> study.
>>
>> My very big +1 for that, with the wish of work directly on that stuff.
>> Anyone else has a different thought, before proceeding?
>> Thanks in advance,
>> Simo
>>
>> [1] http://markmail.org/message/q4y7ghux57s7hk6v
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Wed, Oct 20, 2010 at 7:43 PM, Gary Gregory
>> <ggreg...@seagullsoftware.com> wrote:
>>> In the same department, I see the following ivars:
>>>
>>> lifo : boolean
>>> maxActive : int
>>> maxIdle : int
>>> maxTotal : int
>>> maxWait : long
>>> minEvictableIdleTimeMillis : long
>>> minIdle : int
>>> numTestsPerEvictionRun : int
>>> testOnBorrow : boolean
>>> testOnReturn : boolean
>>> testWhileIdle : boolean
>>> timeBetweenEvictionRunsMillis : long
>>> whenExhaustedAction : WhenExhaustedAction
>>>
>>> defined in four classes:
>>>
>>> GenericKeyedObjectPool
>>> GenericKeyedObjectPoolFactory
>>> GenericObjectPool
>>> GenericObjectPoolFactory
>>>
>>> Which feels to me like a missed opportunity to avoid duplication.
>>>
>>> Is making one ivar private or final or volatile be applied to all four 
>>> classes?
>>>
>>> We could:
>>>
>>> Use a config object instead of the 13 ivars.
>>> Or a common superclass then we can consider if it should hold the ivar list 
>>> or a Config object.
>>>
>>> Would it be too weird to have a common super class for BaseObjectPool and 
>>> BasePoolableObjectFactory for example?
>>>
>>> Gary Gregory
>>> Senior Software Engineer
>>> Rocket Software
>>> 3340 Peachtree Road, Suite 820 . Atlanta, GA 30326 . USA
>>> Tel: +1.404.760.1560
>>> Email: ggreg...@seagullsoftware.com
>>> Web: seagull.rocketsoftware.com
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Gary Gregory [mailto:ggreg...@seagullsoftware.com]
>>>> Sent: Wednesday, October 20, 2010 10:29
>>>> To: Commons Developers List
>>>> Subject: [pool] Reusing Config
>>>>
>>>> Hi All:
>>>>
>>>> I think this came up recently. Any thoughts or plans on extracting the 
>>>> Config
>>>> class out of GenericKeyedObjectPool and GenericObjectPool so it can be 
>>>> reused.
>>>> The constants for default values could then also be moved to Config.
>>>> Gary Gregory
>>>> Senior Software Engineer
>>>> Rocket Software
>>>> 3340 Peachtree Road, Suite 820 * Atlanta, GA 30326 * USA
>>>> Tel: +1.404.760.1560
>>>> Email: ggreg...@seagullsoftware.com<mailto:ggreg...@seagullsoftware.com>
>>>> Web: seagull.rocketsoftware.com<http://www.seagull.rocketsoftware.com/>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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