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

Steve Siebert commented on POOL-173:
------------------------------------

Hmmm...sorry about that last "out of nowhere" comment...I didn't think adding a 
dependency link from the previous ticket would generate a "thread" comment =). 

Anyway, I just uploaded the very basic class diagram for how things currently 
are - I think it easily points out some of the significant issues Gary pointed 
out. It also exposes some other issues that may need to be investigated. 
Unfortunately, the constructor API is already set for the 2.0 
release...depending on how we go with the config, we could probably drop a lot 
of these constructors. We might consider using a Builder pattern to ease the 
programmatic creation of the configuration. 

I'm looking at the diff right now...I'm getting only a partial apply, two 
errors: 
C:\development\commons-pool\trunk\src\java\org\apache\commons\pool2\impl\GenericKeyedObjectPoolFactory.java
 (Cannot apply hunk @@ 434 ) 
C:\development\commons-pool\trunk\src\java\org\apache\commons\pool2\impl\GenericObjectPoolFactory.java
 (Cannot apply hunk @@ 518 ) 

I'll go over the patch and provide some feedback =). 

As I said in the email thread, there are a lot of other issues with 
configuration (initial provisioning/properties file) that we might want to 
consider while doing this re-look. I'll provide some comments on this as well, 
but if I start straying or trying to incorporate too much too fast, let me know 
=) 

S

> 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:[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.

Reply via email to