commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Siebert <smsi...@gmail.com>
Subject Re: [pool] Reusing Config
Date Mon, 25 Oct 2010 13:51:29 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message