I have developed a plugin for SailPoint IdentityIQ that calls web services through a custom-built Java application to retrieve cetrain information. The plugin itself simply invokes Java methods from this application.
However, my Java application uses the same Java classes as SailPoint IdentityIQ but with a different version. I have read that SailPoint and its plugins use seperate ClassLoaders, so in theory, there should be no conflicts. Despite this, I am encountering runtime errors suggesting that the plugin is accessing the wrong classes - specifically, the ones from SailPoint instead of the ones from my plugin/ application.
Has anyone experienced similar issues with ClassLoaders in SailPoint plugins? How can I ensure that the two ClassLoader environments remain completely seperate? Are there any best practices or specific configurations to avoid ClassLoader conflicts?
Oof, yeah, this is troublesome. As you’ve noticed, IIQ plugins don’t use a separate ClassLoader from IIQ itself, but rather a child ClassLoader.
The way class loading works in Java, it will use the first ClassLoader in the hierarchy that’s already loaded a named class. (I’ve actually seen this happen the other direction, too. A plugin ClassLoader will be the first to load, say, Commons Logging classes, and IIQ-level logging will blow up with errors.)
You will need an entirely separate ClassLoader, and that’s unfortunately on you to implement. I usually build the separated classes into their own JAR file(s), put them in META-INF in the JAR (so they don’t get loaded by the JVM), and then unzip the JARs on the fly to build my internal ClassLoader. You can either use a memory-based ClassLoader (which is what IIQ itself does for plugins) or unzip them to a temp folder and use that.