Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] RE: [grouper] Grouper 2.1.5 loses track of ldap connection (#43)

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] RE: [grouper] Grouper 2.1.5 loses track of ldap connection (#43)

Chronological Thread 
  • From: Chris Hyzer <>
  • To: "" <>, "" <>
  • Subject: RE: [grouper-dev] RE: [grouper] Grouper 2.1.5 loses track of ldap connection (#43)
  • Date: Tue, 21 Jul 2015 20:06:43 +0000
  • Accept-language: en-US

Vivek Sachdeva fixed this and it is in API patch 18

Note, see the jira, you need to put some more configuration in the
sources.xml to make LDAP connection validation work.

Please try it out and let us know how it goes :)


-----Original Message-----


Sent: Monday, July 06, 2015 9:52 AM
Chris Hyzer
Subject: Re: [grouper-dev] RE: [grouper] Grouper 2.1.5 loses track of ldap
connection (#43)


I'm a colleague of Hans and took over the problem we are having with invalid
Ldap connections not being cleaned up after a Ldap restart.

When I look into the source code (tag GROUPER_2_1_5) then I can't see how your
suggestion could work. Basically the LdapSourceAdapter reads the properties
file specified by ldapProperties_file. It uses the properties file to read the
credentials and the additional key-values related to tuning the Ldap pool
(e.g. edu.vt.middleware.ldap.pool.validateOnCheckOut) end up in

However when the pool is created (LdapSourceAdapter#initializeLdap line 291):

DefaultLdapFactory factory = new DefaultLdapFactory(ldapConfig);

try {
ldapPool = new SoftLimitLdapPool(factory);
the SoftLimitLdapPool constructor used is the one where the factory is
supplied on the SoftLimitLdapPool and not the other constructor where also the
LdapPoolConfig is provided. As such the SoftLimitLdapPool is initialized with
a new default LdapPoolConfig and the tuning properties specified in the
ldapProperties_file are never used. I debugged our test environment and
confirmed this.

Maybe I'm missing something but I think using the single argument constructor
for the SoftLimitLdapPool with only the factory being provided and not the
LdapPoolConfig is a bug. Could you confirm this?

Again maybe I'm missing something, but when I examined the code I can't figure
out where the SoftLimitLdapPool being used could ever pick up the tuning
properties in the ldapProperties_file as it's creates a new default
LdapPoolConfig which does not validate anything and has a


Archive powered by MHonArc 2.6.16.

Top of Page