[midPoint] Midpoint 3.3 and OpenLDAP

[Shawn McKinney]

> On Jan 7, 2016, at 3:20 AM, Radovan Semancik <radovan.semancik at evolveum.com> wrote:
> 
> How exactly are you using the accelerator?
> 
> The ConnId framework creates a new classloader for each connector so they can be separated (e.g. having several versions of the same connector at the same time). Therefore, if the connector requires some specific library then the best practice is to bundle that library together with the connector. ConnId has a semi-proprietary mechanism for that. Connector dependencies should be placed in the "lib" directory inside the connector JAR file.
> 
> Therefore, if the accelerator is used by the connector, it should be placed inside the connector JAR.
> If the accelerator is used by midPoint code, then it should be placed in the midPoint WAR.
> 
> The stacktrace that you have provided suggest that the accelerator is invoked as an extension of Apache LDAP API during LDAP connector initialization. Therefore your best option is perhaps to fork the LDAP connector on github (https://github.com/Evolveum/connector-ldap), add dependency to the accelerator to the pom.xml and rebuild. The assembly plugin that is used in the connector pom.xml will automatically bundle all dependencies inside the connector JAR.

The dependency chain flows like this:


1. fortress web -> 2. fortress realm -> 3. fortress core -> 4. openldap accelerator -> 5. apache ldap api
                                                                                     -> 5. apache ldap api

Both fortress core and openldap accelerator are dependent on apache ldap api.  We would not be having this conversation right now if fortress web wasn’t also deployed inside the same instance of Tomcat.  When I remove fortress web the classloader problem goes away.  Note that fortress core and openldap accelerator each have dependencies on the accelerator.  I don’t believe that is an important fact at this point.  The fortress web is using the realm.  The realm component is Tomcat plug-in for doing Java EE security checks.  It is a callback mechanism between the container and the fortress libs that reside in the fortress web war.  The mechanism requires a single jar, called the proxy, that is loaded directly onto the system classloader, i.e. server/lib folder.  The proxy jar uses a URL classloader to access the impl jars that reside in the fortress web. 

Now the question is why does any of this matter?  I have not seen any clashes like this before loading multiple fortress related components into a single instance of Tomcat.  However those components would all have the same set of fortress libs also present.

The problem is there is a static initialization that happens inside the apache ldap api.  Since the realm got there first, it would have set this system property:
            System.setProperty( StandaloneLdapApiService.EXTENDED_OPERATIONS_LIST,
                "org.openldap.accelerator.impl.createSession.RbacCreateSessionFactory,"
                    + "org.openldap.accelerator.impl.checkAccess.RbacCheckAccessFactory,"
                    + "org.openldap.accelerator.impl.addRole.RbacAddRoleFactory,"
                    + "org.openldap.accelerator.impl.dropRole.RbacDropRoleFactory,"
                    + "org.openldap.accelerator.impl.deleteSession.RbacDeleteSessionFactory,"
                    + “org.openldap.accelerator.impl.sessionRoles.RbacSessionRolesFactory"


Which tells the ldap api to load these classes.  Later, when midpoint fires up and also loads the apache ldap api into its classloader has the same system properties but yet cannot find the impl classes on its classloader.  

We could work around this issue by loading the accelerator into the midpoint war or connector jar.

Shawn