[DIRAPI-239] Client API exposes implementation classes of common-pools

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Invalid
• Affects Version/s: 1.0.0-M30
• Fix Version/s: 2.0.0.AM3
• Assignee: Unassigned
• Reporter: Federico Marmori
• Created: 05/May/15 11:14
• Updated: 12/May/19 05:52
• Resolved: 09/Jun/18 16:48

Description

The constructors:

LdapConnectionPool(LdapConnectionConfig connectionConfig, LdapApiService apiService, long timeout, org.apache.commons.pool.impl.GenericObjectPool.Config poolConfig)

and

LdapConnectionPool(org.apache.commons.pool.PoolableObjectFactory<LdapConnection> factory, org.apache.commons.pool.impl.GenericObjectPool.Config poolConfig)

...allows the user to provide its own pool configuration.
However, using the Config object is really a bad idea. This forces the user code to depend on an implementation class of the commons-pool library, which will break any OSGI deployment and force the user to implement tedious workarounds. Probably common-pools could solve the issue by exposing the Config object in the API, however the DIRAPI can fix the issue by making sure that the LdapConnectionPool either:

• expose all pool configuration attributes in a constructor instead of the GenericObjectPool.Config
• provide its own LdapPoolConfiguration bean object instead of using the GenericObjectPool.Config
• provide an LdapConnectionPoolFactory instead