I am developing a plugin using a custom API, but the java classes in my project does not show up on my plugin when I run the plugin classes command in the IIQ console, as if they are not working. My file structure looks likes this:
In my lib folder I have the .jar file of the project, generated through maven packaging and containing all the backend classes. But I get the error “javax.servlet.ServletException: java.lang.IllegalStateException: Request scope has been already shut down.” when looking in the logs and trying the API using Postman.
Can you validate if the class files are compiled when running maven install by looking
into the directory target/classes
open the dist-directory in a terminal and run jar tvf .\<artifactId>-<version>.jar (see pom.xml for artifactId and version)
extracting the zip file <artifactId>-<version>.zip
I also noticed issues when installing a plugin via the console. Can you also install the plugin via the UI and see if that makes a difference (assuming the above is correct).
I never install the plugins via the console only UI, but it makes sense that the resource class is not loading but the service class is for example after reading this comment that is a few years old:
Here I got my java service-class to be identified in the console. I had to downgrade my java version to 8 since it was too new. But I still cannot get my API call with Postman to work.
First, I wouldn’t store “Response” as a class level variable. Yes, Jersey will construct a new instance of your PluginManager class for each call, but you may end up with weirdness anyway. Response objects should be returned via the return Response....build() pattern in your method. You shouldn’t ever have to store them anywhere.
(Alternatively, if you use my iiq-common-public library and extend BaseCommonPluginResource instead, you never have to worry about Response objects at all, ever.)
Second, that error can be thrown when an API call hits a previous version of the plugin class, usually because the classloader got screwed up. The old Jersey Application context is indeed shut down, which is what the error is telling you. I’ve seen this happen when you deploy the plugin to one appserver, and then hit the API on a different appserver before the plugin service has propagated the plugin to all servers.
Third, you ought to get any class loading failures on install, not when you call the service. Do you see any errors in the logs on install? They would not appear in the console, but rather in the server logs. They would be prior to all of those ServletExceptions.
Fourth, the folder name in your plugin zip, which should contain the JAR files, is “jars”, not “libs”. The plugin ZIP structure should look something like this example (where RR-obf.jar is the key one). Can you verify that?
Hello, thanks for your reply. The errors in the rolling sailpoint.log is related to ServletExceptions. I think I will try to restart the Tomcat server.
I would read the plugin guide. You’ll need to add an annotation on your resource method, I.e. @AllowAll means any authenticated user could call the endpoint. The guide will explain this.
