Uploaded image for project: 'Directory Client API'
  1. Directory Client API
  2. DIRAPI-239

Client API exposes implementation classes of common-pools

Attach filesAttach ScreenshotWatch issueCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Invalid
    • 1.0.0-M30
    • 2.0.0.AM3
    • None

    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

      Attachments

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            Unassigned Unassigned
            fmarmori Federico Marmori
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Issue deployment