Bug 61302 - Refactoring of DataSourceProxy
Summary: Refactoring of DataSourceProxy
Status: NEW
Alias: None
Product: Tomcat Modules
Classification: Unclassified
Component: jdbc-pool (show other bugs)
Version: unspecified
Hardware: PC All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-15 15:26 UTC by João Paulo Lemes
Modified: 2017-07-16 22:50 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description João Paulo Lemes 2017-07-15 15:26:50 UTC
Hello everyone.
I was analyzing the modularization of some classes, and I identified that the class DataSourceProxy has an opportunity for cohesion improvement. 
The class Http11Protocol was in the same situation and the problem was solved as follows: The HttpBaseProtocol class was created, and several get() and set() methods that were used only to configure the class parameters were moved from Http11Protocol to HttpBaseProtocol. 
The new class was then accessed through an instance variable in Http11Protocol. This strategy has cleaned and improved Http11Protocol cohesion.
With this in mind, I would recommend creating a new class: DataSourceProxyConfig , and moving the following methods:

setDefaultCatalog
getNumTestsPerEvictionRun
setMaxAge
getConnection
setTestWhileIdle
getPropagateInterruptState
getPoolSize
setPassword
setLoginTimeout
getIdle
getDriverClassName
getDataSourceJNDI
setAlternateUsernameAllowed
getValidationInterval
getValidator
setValidationQuery
setUrl
setCommitOnReturn
getPassword
setLogWriter
getDbProperties
setTimeBetweenEvictionRunsMillis
getLogWriter
setValidationInterval
getName
getUseDisposableConnectionFacade
getUrl
getMinIdle
getXAConnection
getRollbackOnReturn
getMaxIdle
getPoolName
getInitSQL
setLogValidationErrors
setRemoveAbandoned
setDefaultAutoCommit
setName
setRollbackOnReturn
getMaxActive
setDataSource
getLogValidationErrors
getJdbcInterceptorsAsArray
setUseDisposableConnectionFacade
getMinEvictableIdleTimeMillis
getRemoveAbandonedTimeout
setDefaultTransactionIsolation
setMinIdle
setValidator
setInitialSize
getConnectionProperties
getInitialSize
setUsername
setUseLock
getMaxAge
getNumActive
getDefaultAutoCommit
setDataSourceJNDI
setValidationQueryTimeout
getSuspectTimeout
getConnectionAsync
setPoolProperties
setJmxEnabled
setPropagateInterruptState
setMaxWait
getPoolProperties
getUseLock
getActive
setAbandonWhenPercentageFull
getNumIdle
getMaxWait
getSize
getParentLogger
setDriverClassName
setLogAbandoned
setRemoveAbandonedTimeout
setTestOnConnect
getAbandonWhenPercentageFull
setAccessToUnderlyingConnectionAllowed
getPooledConnection
setTestOnBorrow
setTestOnReturn
setValidatorClassName
setUseEquals
getUsername
setDbProperties
getTimeBetweenEvictionRunsMillis
setIgnoreExceptionOnPreLoad
getDefaultReadOnly
getCommitOnReturn
setConnectionProperties
getPool
setMaxIdle
setJdbcInterceptors
getDataSource
getWaitCount
getValidationQuery
getValidationQueryTimeout
getDefaultTransactionIsolation
setDefaultReadOnly
getJdbcInterceptors
setFairQueue
getLoginTimeout
getDefaultCatalog
setMaxActive
setSuspectTimeout
setMinEvictableIdleTimeMillis
setNumTestsPerEvictionRun
getValidatorClassName
setInitSQL

from the DataSourceProxy.
Those parameters accessed by an instance variable in the DataSourceProxy.
Moreover, the orthogonality is the design would be enhanced.

What do you think about that?
Comment 1 Mark Thomas 2017-07-16 22:50:44 UTC
Correcting product