Hi,
sorry for not having been clear, but in my previous email my intent
was saying that depending on how we manage the Config class, it could
influence de JMX support design, nothing more, and since I'm not
expert on JMX I was waiting for feedbacks from who knows more than me
About Gary's question, I had the following thought
AbstractGenericObjectPoolConfig
- int maxIdle
- int minIdle
- int maxActive
- long maxWait
- WhenExhaustedAction whenExhaustedAction
- boolean testOnBorrow
- boolean testOnReturn
- boolean testWhileIdle
- long timeBetweenEvictionRunsMillis
- int numTestsPerEvictionRun
- long minEvictableIdleTimeMillis
- boolean lifo
GenericObjectPoolConfig extends AbstractGenericObjectPoolConfig
- long softMinEvictableIdleTimeMillis
GenericKeyedObjectPoolConfig extends GenericObjectPoolConfig
- int maxTotal
About the pools:
class GenericObjectPool {
+ GenericObjectPool(GenericObjectPoolFactory factory) {
this(factory, new GenericObjectPoolConfig());
}
+ GenericObjectPool(GenericObjectPoolFactory factory,
GenericObjectPoolConfig config) {...}
+ GenericObjectPoolConfig getConfig() {...}
}
same thing for the Keyed version.
Too simple and stupid? Maybe. But reduces the redundancies to 0.
Moreover I'm not sure it is just an academical way to approach the
issue, I'm sure it is more than pragmatic, simplifying the
maintainability and makes easier keep in synch the Pool and related
Factory configuration.
Just my 2 cents, now off to bed due my local timezone :P
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Wed, Oct 20, 2010 at 10:40 PM, Gary Gregory
<ggreg...@seagullsoftware.com> wrote:
> So I am doing an experimental refactoring to see what the code would look
> like with a Config class extracted and I ran into the following.
>
> The class GenericObjectPool has an _softMinEvictableIdleTimeMillis ivar but
> the equivalent GenericKeyedObjectPool does not.
>
> Is that a little hole in implementation that could have been avoided with a
> common classes used for config? Even if GenericKeyedObjectPool would throw a
> "not implemented" exception.
>
> Thoughts?
>
> 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: Simone Tripodi [mailto:simone.trip...@gmail.com]
>> Sent: Wednesday, October 20, 2010 12:22
>> To: Commons Developers List
>> Subject: Re: [pool] Reusing Config
>>
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
