Share all details about your problem, including any error messages you may have received.
Hi all,
I’m encountering a persistent issue with my IdentityIQ development environment in IntelliJ. My Maven build completes successfully (using mvn clean install), and my pom.xml includes all the required jars (including identityiq-8.3.jar, connector libraries, etc.). However, when I run a simple test class in IntelliJ, I keep getting the following error:
sailpoint.tools.GeneralException: No prototype context exists
at sailpoint.api.SailPointFactory.createPrivateContext(SailPointFactory.java:313)
at sailpoint.api.SailPointFactory.createContext(SailPointFactory.java:197)
at com.sailpoint.IdentityIQTest.main(IdentityIQTest.java:19)
For context, here’s what I’ve done so far:
Working Environment:
I’m using IntelliJ on macOS.
My IdentityIQ installation is deployed to Tomcat (version: apache-tomcat-9.0.102). The WAR file deploys successfully, and I can access the SailPoint console in the browser without issues.
Test Class:
I created a minimal test class (see below) to try and initialize the IdentityIQ context:
package com.sailpoint;
import sailpoint.api.SailPointContext;
import sailpoint.api.SailPointFactory;
import sailpoint.tools.GeneralException;
import java.io.File;
public class IdentityIQTest {
public static void main(String[] args) {
try {
// Confirm the iiq.properties file is found
File file = new File("/Users/raygarg/IIQ/apache-tomcat-9.0.102/webapps/identityiq/WEB-INF/classes/iiq.properties");
System.out.println("iiq.properties exists: " + file.exists());
// Attempt to create the IdentityIQ context
SailPointContext context = SailPointFactory.createContext();
if (context != null) {
System.out.println("IdentityIQ context initialized successfully!");
} else {
System.out.println("Failed to initialize IdentityIQ context.");
}
} catch (GeneralException e) {
e.printStackTrace();
}
}
}
Run/Edit Configurations in IntelliJ:
I have set the following VM options:
I’ve also experimented with changing the working directory to either:
/Users/raygarg/IIQ/apache-tomcat-9.0.102/webapps/identityiq
or
/Users/raygarg/IIQ/apache-tomcat-9.0.102/webapps/identityiq/WEB-INF/classes
but the error persists.
Additional Notes:
The same iiq.properties file is used in my IntelliJ project as in the Tomcat deployment.
I’m not using any additional tools like embedded Tomcat—the idea is to run this as a standalone Java application in IntelliJ.
Despite all this, I keep getting the “No prototype context exists” error when trying to initialize the IdentityIQ context via SailPointFactory.createContext().
Does anyone know if there’s something small I might be missing in my configuration for standalone testing? Is there any additional initialization step or property I need to set when running IdentityIQ outside of a servlet container?
Any help or insights would be greatly appreciated.
The issue you’re encountering with initializing the SailPoint context in a non-web environment, specifically when running outside of Tomcat, stems from the fact that SailPoint IdentityIQ relies heavily on the servlet container to manage and provide the necessary application context. Directly using SailPointFactory.createContext() in a standalone application can be problematic because it lacks the servlet context setup by Tomcat.
However, you can bypass this limitation by mocking the SailPoint context for testing purposes. This allows you to simulate the behavior of SailPoint’s API and functionality without needing a full servlet environment. Mocking is particularly useful in unit testing scenarios where you want to isolate and test specific components or logic without dependencies on the full application infrastructure.
Here’s an example of how you can set up such a mock using Mockito, which is a popular mocking framework in Java:
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.mockito.Mock;
import org.mockito.MockitoAnnotations;
import sailpoint.api.SailPointContext;
import sailpoint.object.*;
import java.util.*;
import static org.junit.jupiter.api.Assertions.*;
import static org.mockito.Mockito.*;
class RoleManagerTest {
@Mock
private SailPointContext context;
... Some other setup
@Test
public void testCreateRoles_SuccessfulRoleCreation() throws Exception {
List<ManagedAttribute> organisationUnits = List.of(managedAttribute);
when(managedAttribute.getAttribute("parentID")).thenReturn(null); // No parent, root node
when(context.search(eq(ManagedAttribute.class), any(QueryOptions.class))).thenReturn(organisationUnits.iterator());
when(context.search(eq(Bundle.class), any(QueryOptions.class))).thenReturn(Collections.emptyIterator());
doNothing().when(context).commitTransaction();
roleManager.createRoles();
verify(context, times(1)).commitTransaction();
}
Some other tests
...
}
HI I’m at the point where I’m just trying to confirm if I can run some IdentityIQ API code one time without messing up my main installation directory. I followed a suggestion to create a TestServlet.java in my Maven project, then add a servlet mapping snippet in web.xml so I can just go to a URL in my browser and see if my code runs. Specifically, I did something like this:
Then I built a WAR with mvn clean package (it generated SailPointDevEnv-1.0-SNAPSHOT.war in target/), copied that into Tomcat’s webapps folder (in my home directory on mac), and started Tomcat. The idea is that I’d visit http://localhost:8080/SailPointDevEnv-1.0-SNAPSHOT/test and see a “Success” message if the container-based code works. Instead, I keep getting a 404, and I’m not sure if it’s conflicting with my existing IdentityIQ installation (which lives in webapps/identityiq and is still working fine on http://localhost:8080/identityiq).
I’m basically trying to confirm: is this the right approach for testing IdentityIQ APIs inside Tomcat—just creating a servlet, adding the snippet in web.xml, building the WAR, and hitting that new URL? If so, any idea why I might be stuck on 404, even though the WAR is in webapps and Tomcat logs show it deployed? I’d really appreciate any pointers, especially on how to keep my main identityiq deployment separate from this test WAR, or if there’s a recommended “test” approach that won’t clash with my main setup.
@abartkowski @aleksander_jachowicz @paul_hilchey
please help or if refer to someone who knows how to set this up, just oen time i need to get this right and i will know how to do it forever
Almost all IIQ project rely on SSB using ant rather than Maven. If you decide to use maven to build IIQ you’re a bit on your own.
Having said that I do have a question. What are you trying to do? Are you trying to instantiate IIQ server and run something in it?
If so, in essence, that is what iiq console is, a running iiq without web interface. You might want to look at that from this perspective.
For this to work you will need iiq.properties present on the class path.
Try searching compass, I remember there was a description somewhere how to run iiq server like console.
If I understand correctly what you’re aiming for, your goal in this case is not writing unit tests using jUnit, but rather you’d like to do something akin to integration tests. In this regard, I’m not sure if using libraries related to jUnit will help solve your problem. I think a better approach, if it involves direct testing of the source code in a development environment, is to create unit tests. Nevertheless, if you’d like to directly call your local SailPoint IIQ installation from the unit tests, I believe additional configurations are necessary. Firstly, it would be essential to check if you can query a specific SailPoint IIQ URL from your local machine. Following that, if you are able to make this query, the next element would be authentication in IIQ so that you can access the SailPoint API. For this purpose, you could set the client secret in Global Settings under API Authentication. Then use the generated data to connect with SailPoint. If this step works, I would consider how you could connect Java tests (I think not using jUnit) to the IIQ instance; perhaps opening some internal firewalls etc. might be necessary. I would seriously think about what exactly you want to test. An important issue raised by my predecessor is that using Maven is not a standard approach and to reduce errors, it is advisable to use SSB.