ClassLoader and 3rd-party libraries in Plugin

IdentityIQ (IIQ) IIQ Discussion and Questions
3

Have you tested?

I’m running IdentityIQ 8.3 f4b330b4da3-20220427-175259.

I created a class like this:

package test;
public class Greetings {
	public static int version = 1;
}

Generated Greetings-1.0.jar for it, placed it inside /identityiq/WEB-INF/lib and restarted. Then ran a rule in debug mode:

<Source>
  import test.*;
  return Greetings.version;
</Source>

And I got class not found exception. Apparently not everything in /identityiq/WEB-INF/lib gets added to classpath.

So instead I placed Greetings-1.0.jar in /tomcat9.0/lib and restarted. That worked:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Integer PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Integer>1</Integer>

Then I updated Greetings.jar to version 2. This Greetings-2.0.jar I did NOT copy to /identityiq/WEB-INF/lib nor /tomcat9.0/lib.

Instead I created a plugin, referenced Greetings-2.0.jar. I packaged Greetings-2.0.jar inside /lib folder, like so:

Plugin.zip
    \lib
        \Greetings-2.0.jar
    \[plugin package]
        \[plugin classes]

In my plugin class I exposed a simple REST:

    @POST
	@Path("test")
	public Response test() {
		return Response.ok().entity(Greetings.version).build();
	}

I ran the rule, I got 1. I called the plugin’s REST API, I got 2. It seems the plugin class loader has precedence over IdentityIQ classloader.

I’ve been putting 3rd party JARs (MyBatis, Log4J, Jackson XML, etc.) inside a plugin ZIP’s lib folder since IdentityIQ 7.2, never had any issues finding the classes. Though the libraries loading configuration files do not work (e.g. MyBatis and Log4j), the workaround is to initialize them programmatically when plugin is first loaded.

So just put the JAR inside plugin’s lib folder and it should work. Did you see a different behavior?

2 Likes