commons-issues mailing list archives

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

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