commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: [pool] Reusing Config
Date Mon, 25 Oct 2010 14:02:39 GMT
Hi Steven :)
thanks for the explanation, as far as I understand there are a lot of
things I can learn from you about JMX so I started feeling impatient
to see your commits :P

I don't think we should mark with @Deprecate removed ctors, classes
are now living in a fresh new package so, as user, I wouldn't expect
retro-compatibility at all. When upgrading a major revision, I expect
a completely (or partially, in that case) new version of the
library... maybe I'm wrong but my instinct suggests me a 2.0 version
could be even a completely rewrite of the 1.5.
BTW that's just my opinion :P

Have a nice day,
Simo

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



On Mon, Oct 25, 2010 at 3:51 PM, Steven Siebert <smsiebe@gmail.com> wrote:
> Simone,
>
> I'm sorry I'm confusing, so many thoughts going though my mind =)
>
> yes, I think the best approach is to provide a separate class for the
> JMX...but I'm thinking that doing a private inner class (non-static) in each
> pool would be the cleanest way to do so.  This way, the MBean (instance)
> would have direct access to both the config values (read/write) as well as
> the ability to invoke pool methods (such as getNumwaiters(), POOL-159).
> This would significantly cut down on the bootstrapping of having to register
> the config and pool with the MBean.
>
> Once I get home, I'll attach a JMX patch to POOL-172 using your latest
> commit.
>
> I noticed your two JIRA tickets for the concurrency and builder
> pattern....should one be submitted to add the @deprecated tag to the 1.5 API
> for the various classes, methods, and constructors we're blowing away?
>
> On Mon, Oct 25, 2010 at 9:30 AM, Simone Tripodi <simone.tripodi@gmail.com>wrote:
>
>> Hi Steven,
>> very sorry to have missed the Jira notifications, just checked now
>> after read your email. Sorry! :(
>>
>> I thought the idea was adding JMX support directly on factory/pool and
>> not on Configuration, btw not being JMX expert this will be a good
>> chance to learn... I'll fill a new Jira issue for adding thread safety
>> support on configuration classes, and start to study how to do it in
>> the best way.
>>
>> I like the Builder idea, my +1 for that, take it in consideration as
>> already done :P
>>
>> Have a nice day and thanks for the feedbacks!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/<http://people.apache.org/%7Esimonetripodi/>
>> http://www.99soft.org/
>>
>>
>>
>> On Mon, Oct 25, 2010 at 3:06 PM, Steven Siebert <smsiebe@gmail.com> wrote:
>> > Hi Simone,
>> >
>> > You have two +1's waiting for you in the JIRA comments =)
>> >
>> > My comments from tracker:
>> >
>> > "I took a look at this last night but didn't get a chance to comment =)
>> >
>> > I like the patch, I believe this does indeed satisfy the issue.
>> >
>> > One question I have, since we're eliminating the primitive configuration
>> > properties within the pool/factory classes, we're making the Config
>> objects
>> > publicly accessible, and possibly accessing through JMX is the idea of
>> > making the Config objects thread-safe. This would certainly reduce the
>> need
>> > to have to externally synchronize (and possibly introduce bugs) every
>> time.
>> >
>> > Another issue we probably need to open another ticket for is to deprecate
>> > the constructors we've eliminated in 1.5.
>> >
>> > Last suggestion/question is about making inner (public static final)
>> Builder
>> > pattern classes within the concrete Config classes (and possibly defining
>> an
>> > abstract <T extends Abstract*Config> create() method in the Abstract
>> class).
>> > This would further simplify the programmatic creation of the Config
>> classes.
>> >
>> > Thoughts?
>> >
>> > +1 on Simones patch...we can add any of the above after it has been
>> > committed."
>> >
>> >
>> > Respectfully,
>> >
>> >
>> > Steve
>> >
>> >
>> >
>> > On Mon, Oct 25, 2010 at 8:36 AM, Simone Tripodi <
>> simone.tripodi@gmail.com>wrote:
>> >
>> >> Hi all mates,
>> >> I updated the jira issue uploading my patch; it contains the
>> >> configuration extraction and some code modification.
>> >> IMHO we shouldn't replicate the same data in both configuration AND
>> >> factory/pool, when creating the factory/pool it is enough storing the
>> >> configuration reference, just use it.
>> >> I intentionally missed the interfaces layer, since they can be added
>> >> directly in the JMX support in the required form.
>> >> Please take a look at the patch and provide feedbacks, if you agree I
>> >> could start committing the modifications and proceed on JMX support.
>> >> Have a nice day,
>> >> Simo
>> >>
>> >> http://people.apache.org/~simonetripodi/<http://people.apache.org/%7Esimonetripodi/>
>> <http://people.apache.org/%7Esimonetripodi/>
>> >> http://www.99soft.org/
>> >>
>> >>
>> >>
>> >> On Fri, Oct 22, 2010 at 5:23 AM, Gary Gregory
>> >> <GGregory@seagullsoftware.com> wrote:
>> >> >> -----Original Message-----
>> >> >> From: Steven Siebert [mailto:smsiebe@gmail.com]
>> >> >> Sent: Thursday, October 21, 2010 18:08
>> >> >> To: Commons Developers List
>> >> >> Subject: Re: [pool] Reusing Config
>> >> >>
>> >> >> Gary,
>> >> >>
>> >> >> Great work so far.  I'm checking out the diffs now, I'm gonna
hack
>> out
>> >> some
>> >> >> simple UML "diffs", if only to wrap my head around it all. I'll
>> upload
>> >> the
>> >> >> file to the issue once complete.
>> >> >>
>> >> >> BTW, I hope I didn't offend with the 'academic' comment, I
>> >> >> most certainly did not intend to infer that there weren't functional
>> >> >> importances to this issue.  I was mostly trying to delineate the
two
>> >> issues
>> >> >> in my mind, and putting it to "paper" was a good way to do that
=)
>> >> >>
>> >> >> Cheers,
>> >> >>
>> >> >> S
>> >> >
>> >> > Hi Steven,
>> >> >
>> >> > No offense even considered from this end :)
>> >> >
>> >> > I'm glad we are going through this exercise. This will improve the
>> >> software I am sure.
>> >> >
>> >> > Gary
>> >> >
>> >> >>
>> >> >>
>> >> >> On Thu, Oct 21, 2010 at 3:35 PM, Gary Gregory
>> >> >> <GGregory@seagullsoftware.com>wrote:
>> >> >>
>> >> >> > > -----Original Message-----
>> >> >> > > From: Phil Steitz [mailto:phil.steitz@gmail.com]
>> >> >> > > Sent: Thursday, October 21, 2010 06:29
>> >> >> > > To: Commons Developers List
>> >> >> > > Subject: Re: [pool] Reusing Config
>> >> >> > >
>> >> >> > > On 10/21/10, Simone Tripodi <simone.tripodi@gmail.com>
wrote:
>> >> >> > > > it seems you've been doing a very good work, the
only thing I
>> >> *suggest*
>> >> >> > is
>> >> >> > > >
>> >> >> > > > * simplifying the mutable/immutable interfaces,
one interface
>> for
>> >> >> > > > already known common (im)mutable fields should be
enough;
>> >> >> > > > * adding/renaming the interfaces with the <PoolName>`MBean`
>> >> postfix to
>> >> >> > > > be ready for JMX support;
>> >> >> > > >
>> >> >> > > > btw it seems you're now much more deep inside the
topic than me
>> ;)
>> >> >> > > >
>> >> >> > > > WDYT?
>> >> >> > > > Simo
>> >> >> > > >
>> >> >> > >
>> >> >> > > Sorry I have been a little slow on this.  I will have
a careful
>> look
>> >> >> > > this eve.  Based on a very quick review, I am +1 on
the idea and
>> >> >> > > approach to separate mutable / immutable.  Also +1 for
JMX
>> support.
>> >> >> > > Two quick things to keep top of mind:
>> >> >> > >
>> >> >> > > 1.  Please make sure not to lose documentation.  Whatever
is
>> >> >> > > documented today in protected field / internal getters
/ setters
>> >> docs
>> >> >> > > needs to be carried forward.
>> >> >> >
>> >> >> > Check. I did not check as I refactored that Javadocs were
in the
>> right
>> >> >> > places. That would be a requirement for a real patch. I only
meant
>> >> this as
>> >> >> > an experiment that went a lot further than I thought.
>> >> >> >
>> >> >> > >
>> >> >> > > 2. Somewhat related - I am fine just plowing ahead for
now using
>> >> >> > > existing API concepts, but some of those concepts are
>> anachronistic
>> >> or
>> >> >> > > broken, IMO, so we may later decide to revamp much of
the
>> >> "accounting"
>> >> >> > > aspects of the  API.  That we should and will discuss
on other
>> >> >> > > threads.  One thing that might be good to think about
at this
>> point,
>> >> >> > > however, is getting rid of primitive properties (we started
that
>> >> with
>> >> >> > > whenExhaustedAction).  I think there is a DBCP issue
on this
>> raised
>> >> by
>> >> >> > > Dain a couple of years ago.
>> >> >> >
>> >> >> > It would be nice to track this someplace, I am not sure if
Javadoc
>> is
>> >> the
>> >> >> > right place.
>> >> >> >
>> >> >> > Gary
>> >> >> >
>> >> >> > >
>> >> >> > > Thanks all for moving this along!
>> >> >> > >
>> >> >> > > Phil
>> >> >> > > > http://people.apache.org/~simonetripodi/<http://people.apache.org/%7Esimonetripodi/>
>> <http://people.apache.org/%7Esimonetripodi/>
>> >> >> > > > http://www.99soft.org/
>> >> >> > > >
>> >> >> > > >
>> >> >> > > >
>> >> >> > > > On Thu, Oct 21, 2010 at 8:23 AM, Gary Gregory
>> >> >> > > > <GGregory@seagullsoftware.com> wrote:
>> >> >> > > >>> -----Original Message-----
>> >> >> > > >>> From: Simone Tripodi [mailto:simone.tripodi@gmail.com]
>> >> >> > > >>> Sent: Wednesday, October 20, 2010 22:41
>> >> >> > > >>> To: Commons Developers List
>> >> >> > > >>> Subject: Re: [pool] Reusing Config
>> >> >> > > >>>
>> >> >> > > >>> Hi Gary!
>> >> >> > > >>> unfortunately the link replied with 404
code, can you give me
>> >> please
>> >> >> > > >>> the issue ID?
>> >> >> > > >>
>> >> >> > > >> It's https://issues.apache.org/jira/browse/POOL-173
>> >> >> > > >>
>> >> >> > > >> I've updated the diff file a couple of times
since my initial
>> >> msg.
>> >> >> > > >>
>> >> >> > > >> Gary
>> >> >> > > >>
>> >> >> > > >>> Many thanks in advance, have a nice day!!!
>> >> >> > > >>> Simo
>> >> >> > > >>>
>> >> >> > > >>> http://people.apache.org/~simonetripodi/<http://people.apache.org/%7Esimonetripodi/>
>> <http://people.apache.org/%7Esimonetripodi/>
>> >> >> > > >>> http://www.99soft.org/
>> >> >> > > >>>
>> >> >> > > >>>
>> >> >> > > >>>
>> >> >> > > >>> On Thu, Oct 21, 2010 at 12:16 AM, Gary Gregory
>> >> >> > > >>> <GGregory@seagullsoftware.com> wrote:
>> >> >> > > >>> > Hi Simone,
>> >> >> > > >>> >
>> >> >> > > >>> > Please see my experiment in progress
here
>> >> >> > > >>>
>> >> >> >
>> >>
>> https://issues.apache.org/jira/secure/attachment/12457710/pool2config.diff
>> >> >> > > >>> >
>> >> >> > > >>> > Gary Gregory
>> >> >> > > >>> > Senior Software Engineer
>> >> >> > > >>> > Rocket Software
>> >> >> > > >>> > 3340 Peachtree Road, Suite 820 * Atlanta,
GA 30326 * USA
>> >> >> > > >>> > Tel: +1.404.760.1560
>> >> >> > > >>> > Email: ggregory@seagullsoftware.com
>> >> >> > > >>> > Web: seagull.rocketsoftware.com
>> >> >> > > >>> >
>> >> >> > > >>> >
>> >> >> > > >>> >
>> >> >> > > >>> >> -----Original Message-----
>> >> >> > > >>> >> From: Simone Tripodi [mailto:simone.tripodi@gmail.com]
>> >> >> > > >>> >> Sent: Wednesday, October 20, 2010
14:53
>> >> >> > > >>> >> To: Commons Developers List
>> >> >> > > >>> >> Subject: Re: [pool] Reusing Config
>> >> >> > > >>> >>
>> >> >> > > >>> >> 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://people.apache.org/%7Esimonetripodi/>
>> <http://people.apache.org/%7Esimonetripodi/>
>> >> >> > > >>> >> http://www.99soft.org/
>> >> >> > > >>> >>
>> >> >> > > >>> >>
>> >> >> > > >>> >>
>> >> >> > > >>> >> On Wed, Oct 20, 2010 at 10:40 PM,
Gary Gregory
>> >> >> > > >>> >> <GGregory@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: ggregory@seagullsoftware.com
>> >> >> > > >>> >> > Web: seagull.rocketsoftware.com
>> >> >> > > >>> >> >
>> >> >> > > >>> >> >
>> >> >> > > >>> >> >
>> >> >> > > >>> >> >> -----Original Message-----
>> >> >> > > >>> >> >> From: Simone Tripodi [mailto:simone.tripodi@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://people.apache.org/%7Esimonetripodi/>
>> <http://people.apache.org/%7Esimonetripodi/>
>> >> >> > > >>> >> >> http://www.99soft.org/
>> >> >> > > >>> >> >>
>> >> >> > > >>> >> >>
>> >> >> > > >>> >> >>
>> >> >> > > >>> >> >> On Wed, Oct 20, 2010 at
9:17 PM, Gary Gregory
>> >> >> > > >>> >> >> <GGregory@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.tripodi@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://people.apache.org/%7Esimonetripodi/>
>> <http://people.apache.org/%7Esimonetripodi/>
>> >> >> > > >>> >> >> >> http://www.99soft.org/
>> >> >> > > >>> >> >> >>
>> >> >> > > >>> >> >> >>
>> >> >> > > >>> >> >> >>
>> >> >> > > >>> >> >> >> On Wed, Oct 20,
2010 at 7:43 PM, Gary Gregory
>> >> >> > > >>> >> >> >> <GGregory@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: ggregory@seagullsoftware.com
>> >> >> > > >>> >> >> >>> Web: seagull.rocketsoftware.com
>> >> >> > > >>> >> >> >>>
>> >> >> > > >>> >> >> >>>
>> >> >> > > >>> >> >> >>>
>> >> >> > > >>> >> >> >>>> -----Original
Message-----
>> >> >> > > >>> >> >> >>>> From:
Gary Gregory [mailto:
>> >> GGregory@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:
>> >> >> > > >>> >> ggregory@seagullsoftware.com<mailto:
>> >> ggregory@seagullsoftware.com>
>> >> >> > > >>> >> >> >>>> Web:
>> >> >> > > >>> >> seagull.rocketsoftware.com<
>> >> http://www.seagull.rocketsoftware.com/
>> >> >> > >
>> >> >> > > >>> >> >> >>>>
>> >> >> > > >>> >> >> >>>
>> >> >> > > >>> >> >> >>>
>> >> >> > > >>> >> >> >>>
>> >> >> > ----------------------------------------------------------------
>> >> >> > > ----
>> >> >> > > >>> -
>> >> >> > > >>> >> >> >>> 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
>> >> >> >
>> >> >> >
>> >> >> >
>> ---------------------------------------------------------------------
>> >> >> > 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