commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory (JIRA)" <j...@apache.org>
Subject [jira] Commented: (POOL-173) Better config without duplication.
Date Fri, 22 Oct 2010 07:46:16 GMT

    [ https://issues.apache.org/jira/browse/POOL-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923794#action_12923794
] 

Gary Gregory commented on POOL-173:
-----------------------------------

Thank you for the diagrams. I do not like the constructor zoo either. 

IMO, these constructors should allow to build legal instances. Since there are default values
for all config options, I would argue that we need one constructor that lets you set them
all and one that lets you set none which means you get the defaults. I would also have a constructor
that accepts a config object.

For example, instead of:

- GenericObjectPool(PoolableObjectFactory<T>)
- GenericObjectPool(PoolableObjectFactory<T>, Config)
- GenericObjectPool(PoolableObjectFactory<T>, int)
- GenericObjectPool(PoolableObjectFactory<T>, int, WhenExhaustedAction, long)
- GenericObjectPool(PoolableObjectFactory<T>, int, WhenExhaustedAction, long, boolean,
boolean)
- GenericObjectPool(PoolableObjectFactory<T>, int, WhenExhaustedAction, long, int)
- GenericObjectPool(PoolableObjectFactory<T>, int, WhenExhaustedAction, long, int, boolean,
boolean)
- GenericObjectPool(PoolableObjectFactory<T>, int, WhenExhaustedAction, long, int, boolean,
boolean, long, int, long, boolean)
- GenericObjectPool(PoolableObjectFactory<T>, int, WhenExhaustedAction, long, int, int,
boolean, boolean, long, int, long, boolean)
- GenericObjectPool(PoolableObjectFactory<T>, int, WhenExhaustedAction, long, int, int,
boolean, boolean, long, int, long, boolean, long)
- GenericObjectPool(PoolableObjectFactory<T>, int, WhenExhaustedAction, long, int, int,
boolean, boolean, long, int, long, boolean, long, boolean)

You only need:

- GenericObjectPool(PoolableObjectFactory<T>)
- GenericObjectPool(PoolableObjectFactory<T>, Config)
- GenericObjectPool(PoolableObjectFactory<T>, int, WhenExhaustedAction, long, int, int,
boolean, boolean, long, int, long, boolean, long, boolean)

The other constructors are just noise IMO.

> Better config without duplication.
> ----------------------------------
>
>                 Key: POOL-173
>                 URL: https://issues.apache.org/jira/browse/POOL-173
>             Project: Commons Pool
>          Issue Type: Improvement
>            Reporter: Gary Gregory
>            Priority: Minor
>             Fix For: 2.0
>
>         Attachments: commons-pool2-configExisting.dia, commons-pool2-configExisting.png,
pool2config.diff
>
>
> There is code duplication in configuration code.
> I'd like to track an experiment here.
> > -----Original Message-----
> > From: Gary Gregory [mailto:GGregory@seagullsoftware.com]
> > Sent: Wednesday, October 20, 2010 10:44
> > To: Commons Developers List
> > Subject: RE: [pool] Reusing Config
> > 
> > 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/>
> > >
> > 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message