[
https://issues.apache.org/jira/browse/POOL-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12924530#action_12924530
]
Phil Steitz commented on POOL-173:
----------------------------------
Great work, guys!
I agree with Gary that we don't need all of the primitive type-based
constructors and even with Simone's elimination of them altogether. Can anyone
see a reason that we need to retain these?
+1 for committing Simone's patch as a start. As I said on the ML, we may want
to look at redefining some of the config parameters, but for now, this
refactoring of the constructors and config setup is a good start, IMO.
I have never liked the stateful factories, which look even more silly now once
constructors just use Config objects. I am tempted to suggest that we make
them stateless; but I know that will cause some trauma in the DBCP JNDI setup.
I have not fully thought through how to work around that problem, but I am sure
there is a way.
For now, unless others see problems with it, I suggest Simone commits the last
patch above, we can resolve this issue and open others for further improvements.
> 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,
> pool173-better_config_without_duplication.diff, pool2config.diff
>
>
> There is code duplication in configuration code.
> I'd like to track an experiment here.
> > -----Original Message-----
> > From: Gary Gregory [mailto:[email protected]]
> > 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: [email protected]
> > Web: seagull.rocketsoftware.com
> >
> >
> >
> > > -----Original Message-----
> > > From: Gary Gregory [mailto:[email protected]]
> > > 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: [email protected]<mailto:[email protected]>
> > > 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.
