Trouble Shooting Tips for Policy Agents 2.2 for Sun Application Server 9.x or GlassFish
See All OpenSSO Policy Agents 2.2 ToubleShooting page for other agents.
This is an informal and unofficial additional resource to help you fix a problem when you are installing or configuring a policy agent 2.2 on the Sun 9.x application server and also the GlassFish application server. The agent that is being installed is appserver_v9_agent.zip
Start by checking:
- The official guide trouble shooting section
- Release Notes have some known issues that you may be experiencing
Extra Trouble Shooting Tips
Feel free to add your own at the end of the list below
List of Problems/Solutions and Links to Help
On this page...
- General Tips, like setting & getting log information to help determine problem
- Installation unsuccessful but did not notice
- Installation with Mis-matched application server instance name and actual server instance name in the application server's domain.xml
- Installed Agent on same domain as the Access Manager fam/am/opensso server
- Trying to install same agent unzipped download bits on another domain
- Agent Profile information is not correct
- Access Manager Server is not available
- Sample Application Problems
- Installation Fails due to use of incorrect agent version download
- Redirect Errors or loops(browser redirect error message), though user seems logged in, can see User Edit page on AM UI console
On other pages
Detailed Problems and Solutions
Each of these common problems and solutions is documented below.
A Couple general tips for trouble shooting
PROBLEM:
If you have problems when installing, or configuring an agent, there are a couple of good places to start looking and get more info to determine the problem
SOLUTION:
- Installation Logs : During installation, all the activity is stored in a special set of log files. Look inside j2ee_agents\appserver_v9_agent\logs\debug\Agent.log file (and also in j2ee_agents\appserver_v9_agent\logs\audit\ install.log file)to see all the activity that is logged druing installation. Check for any exceptions or unsuccessful installation messages.
- Agent Runtime Logs : During run time, the agents log all the debug info in the agent instance debug directory in different files (for example in j2ee_agents\appserver_v9_agent\Agent_001\logs\debug|) and you can look in those files for any error messages or exceptions.
- Increase Debug Logging Level: Customize the debug logging level settings to get more info. You must stop your application server domain, then edit the AMAgent.properties file for the agent instance (for example in ...\j2ee_agents\appserver_v9_agent\Agent_001\config\AMAgent.properties) and changing the property com.iplanet.services.debug.level from error to message level. By default it is set to com.iplanet.services.debug.level=error but you can set it to com.iplanet.services.debug.level=message and see a lot more informaton.
- Application Server Logs: Besides just agent logs, you could also check the application server specific logs. Each domain has a separate logging place such as glassfish\domains\domain1\logs\ which contains a log file called "server" which contains some useful info. You can look there for exceptions and error messages.
Installation unsuccessful but did not notice
PROBLEM:
You see a bunch of class not found exceptions for agent related classes.
When installing the agent it may not have occurred successfully, but you do not notice, and you continue on to the next steps. Then may be when you deploy the agent houskeeping application or an application protected by the agent and you see a class not found exception for the agent related classes. During the installation process, the agent installer modifies the application server's domain.xml by adding some of the agent related resources into the app servers classpath. Since installation was unsuccessful and failed, when the agent houskeeping application or portected app is launched or at application launch time or server start up time they will see a bunch of class not found exceptions for the agent classes(this is true for many unsuccessful installation issues).
Symptom 1: When you deploy the agent housekeeping application agentapp.war (or another of your own agent protected apps which have the agent filter referenced in their web.xml) on the app server, the application server's domain server log such as glassfish\domains\domain1\logs\server.log contians this
Exception starting filter Agent java.lang.ClassNotFoundException: com.sun.identity.agents.filter.AmAgentFilter at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1498) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:235) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:369) at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:103) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4381) at org.apache.catalina.core.StandardContext.start(StandardContext.java:5181) at com.sun.enterprise.web.WebModule.start(WebModule.java:327)
Symptom 2: When you try to launch the agent application from the application server console or just try to go to agent url manually in your browser and the agent application url (like
http://your.test.domain:8080/agentapp
) in the browser gives you a HTTP Status 503 error page so you see this in your browser page
HTTP Status 503 - -------------------------------------------------------------------------------- type Status report message descriptionThe requested service () is not currently available. -------------------------------------------------------------------------------- Sun Java System Application Server 9.1
SOLUTION:
Run the agentadmin --uninstall and uninstall the agent from the associated domain. Then re-run the agent installer again on that domain.
Make sure that the application server domain is stopped when you install (or uninstall) the agent. Also, make sure that you have the proper permissions on the domain.xml file of the application server domain that you are installing on, else the installer will not be able to edit/update it successfully. Also, if you are running the Access Manager server on the same application server installation, then you should install the agent on a separate domain, as having them co-located on the same domain causes problems during installation.
Installation with Mis-matched application server instance name and actual server instance name in the application server's domain.xml
PROBLEM:
This problem can be seen in various ways, so there are a few symptoms to look for.
Symtpom 1: During agent installation, after answering all the questions, and viewing summary of your responses, you see something like this in the terminal window...
Adding Agent parameters to ...glassfish\domains\domain1\config\domain.xml file ...FAILED. 1. Continue with Installation 2. Undo Changes 3. Abort Installation & Exit Please make your selection [1]:
Symtpom 2 :Another symptom you may see, if you do not notice that FAILED message at agent installation time, is when you deploy the agent houskeeping application or deploy an application protected by the agent and you see a class not found exception with messages saying that it can not find agent related classes. This is because the agent installation failed so the domain.xml did not get properly edited/updated with the right classpath settings to use agents.
Symptom 3: In the Agent.log file (inside j2ee_agents\appserver_v9_agent\logs\debug\ directory) You see a Null Pointer Exception like this ConfigureDomainXMLTask.execute() Error occurred while updating serverXML file 'C:\workspace\test-fam\glassfish\domains\domain41\config/domain.xml'. java.lang.NullPointerException at com.sun.identity.agents.install.appserver.v81.DomainXMLBase.getInstanceConfigName(DomainXMLBase.java:274) at com.sun.identity.agents.install.appserver.v81.DomainXMLBase.getInstanceConfig(DomainXMLBase.java:286) at com.sun.identity.agents.install.appserver.v81.ConfigureDomainXMLTask.execute(ConfigureDomainXMLTask.java:62) at com.sun.identity.install.tools.configurator.TaskRunner.executeTask(TaskRunner.java:101) at com.sun.identity.install.tools.configurator.TaskRunner.runTasks(TaskRunner.java:68) at com.sun.identity.install.tools.configurator.InstallDriver.install(InstallDriver.java:90) at com.sun.identity.install.tools.configurator.InstallDriver.install(InstallDriver.java:35) at com.sun.identity.install.tools.handler.InstallHandler.handleRequest(InstallHandler.java:57) at com.sun.identity.install.tools.admin.AdminTool.dispatch(AdminTool.java:223) at com.sun.identity.install.tools.admin.AdminTool.run(AdminTool.java:126) at com.sun.identity.install.tools.launch.AdminToolLauncher.launchAdminTool(AdminToolLauncher.java:173) at com.sun.identity.install.tools.launch.AdminToolLauncher.main(AdminToolLauncher.java:285)
Symptom 4: In the install.log file (inside j2ee_agents\appserver_v9_agent\logs\audit\ directory) you see a message something like this near the end:
[10/04/2007 18:41:45:130 PDT] Adding Agent parameters to C:\workspace\test-fam\glassfish\domains\domain41\config/domain.xml file ...FAILED.
If you are curious as to the REASON the problem occurs:
This error can occur during installation when a user supplies the wrong server name for this question :
Enter the name of the Application Server instance that is secured by this Agent. [ ? : Help, < : Back, ! : Exit ] Enter the Application Server Instance name [server]: (user enters the wrong name here!)
The agent installer uses this server name to locate the proper server element in the domain.xml of the application server domain. The server name is an attribute on <server name="server" ... > as in this snippet of domain.xml
<servers>
<server name="server" config-ref="server-config" lb-weight="100">
<application-ref enabled="true" ref="adminapp" virtual-servers="__asadmin" lb-enabled="false" disable-timeout-in-minutes="30"/>
.............
</server>
</servers>
<property name="administrative.domain.name" value="domain1"/>
</domain>
By default Sun appserver 9 (GlassFish) uses "server" as the name, though you can customize it if desired. Check the domain.xml for example in your-app-server-installation\domains\domain1\config\domain.xml file and look at the name for app server instance and make sure it matches what you input to installer when it asks for the name of the Application Server instance that is secured by this Agent.
SOLUTION:
First, run the agentadmin --uninstall and unintstall the unsuccessful partial install you tried to do on the chosen app server domain
Then, run the agentadmin --install again, and supply the application server instance name with a value that matches the domain.xml value, such as Enter the name of the Application Server instance that is secured by this Agent. [ ? : Help, < : Back, ! : Exit ] Enter the Application Server Instance name [server]: server
Installed Agent on same domain as the Access Manager fam/am/opensso server
PROBLEM:
Trying to install an agent on the same domain or instance that you have already installed the Access Manager am server war often causes many problems. Both the agent and the am server installations modify the application server's domain.xml including classpath settings, and often this results in conflicts. Hence you may see class not found or other classpath related issues and messages in logs etc.
SOLUTION:
It is highly recommended to always install the agent on a separate domain from the domain where you have installed the Access Manager am server. It is easy to create another domain on Sun 9.x (GlassFish) app server. Each domain is independent and can be modified without affecting other domains. This gives nice isolation when configuring both the agent and the Access Manager am server on the same application server installation. You can easily create a new domain on the Sun 9.x (GlassFish) app server running a command such as this from the app server's bin/ directory "asadmin create-domain --portbase 6868 --user admin domain2" with your own choices for 6868,admin, domain2.
Although, sometimes people can sort of fix the issue by editting classpath setting and other config info, this almost alwyas results in a problem later on. If you want to use the agent and the am server on the same application server installation, then create a new separate application server domain for the agent and install the agent on your new domain.
Here is a recipe to fix the problem:
- Undeploy the agentapp.war and the sampleapp.ear from the domain, if you have already deployed them on the app server.
- Stop the app server domain
- Uninstall the agent. Got to bin\ directory where you unzipped your agent, like \j2ee_agents\appserver_v9_agent\bin and run the command "agentadmin --uninstall" and specify the old domain where you previously installed the agent.
- Create a new domain, running a command such as this from the app server's bin/ directory "asadmin create-domain --portbase 6868 --user admin domain2" with your own choices for 6868,admin, domain2.
- Make sure the new app server domain is stopped, in case you started it.
- Install the agent on the new domain, run "agentadmin --install".
- Make sure to specify the new domain directory during agent installation questions.
- Also, be sure to answer false when asked if installing on the same instance.
Enter true if the Agent is being installed on the same instance of Application Server on which Access Manager is deployed. Enter false if that is not the case. [ ? : Help, < : Back, ! : Exit ] Are the Agent and Access Manager installed on the same instance of Application Server ? [false]:
- Do the rest of the set up steps such as deploying the agentapp.war on the new domain.
- Also, if you had previously tried to install the agent and am server on the same domain instance, and you had already done the special post-installation step for this of modifying the Access Managers AMConfig.properties (note this is not the agent's properties but is the am server's properties) by adding the "com.sun.identity.agents.config.location property= ..." then please go and remove this property from the AMConfig.properties and restart the app server domain so this property is not used. That property is only when trying to install on the same instance and installaing on the same instance is exactly what we are trying to avoid here since it often does not work properly.
Trying to install same agent unzipped download bits on another domain
PROBLEM:
If you unzipped the appserver_v9_agent.zip agent and then used the agent installer to install an agent correctly on a domain1, then when you try to install another agent Agent on same app server but different domain2, and when running "agentadmin --install" you see an error like this in the terminal window ...
ERROR: Installation failed due to the following error - (The agent
installation state for this Application Server is in corrupted state.
Unable to retrieve the agent state.).
SOLUTION:
You can not use the same agent bits to install on different domains of the same application server installation. You need to unzip the appserver_v9_agent.zip agent and use these new bits if you want to install on another domain.
Agent Profile information is not correct.
PROBLEM:
Incorrect agent profile name and/or password. When you install/configure an agent, you choose an agent profile name and also password associated with that agent profile. This profile info is used by the agent to communicate with the Access Manager server. This password AND profile name must be the same as what you created on the Access Manager server. If you installed the agent(it asks 2 questions for agent profile name and password file) or configure the agent with the wrong password or change it incorrectly at some time so there is a mismatch, then the agent protected apps will not work and you will see errors. Same thing if you entered the wrong profile name. Or maybe you forgot to create the agent profile on the Access Manager.
Symptom 1: When you try to use your agent-protected applications or launch the agent application from the application server console or just try to go to agent url manually in your browser and the agent application url (like
http://your.test.domain:8080/agentapp
) in the browser, it gives you a HTTP Status 500 error page. So you see this in your browser page
HTTP Status 500 - type Exception report message descriptionThe server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException: PWC1243: Filter execution threw an exception root cause java.lang.NoClassDefFoundError note The full stack traces of the exception and its root causes are available in the Sun Java System Application Server 9.1 logs. Sun Java System Application Server 9.1
Symptom 2: The agent debug log file amRemotePolicy.log (in a directory like j2ee_agents\appserver_v9_agent\Agent_001\logs\debug)contains this error message
ERROR: PolicyEvaluator.getNewAppSSOToken():, cannot obtain application SSO token
Symptom 3: The agent debug log file amWebPolicy.log (in a directory like j2ee_agents\appserver_v9_agent\Agent_001\logs\debug)contains error messages like these :
ERROR: AmWebPolicyManager initialization failed [AgentException Stack] com.sun.identity.agents.arch.AgentException: Unable to load IAmWebPolicy: com.sun.identity.agents.policy.AmWebPolicy at com.sun.identity.agents.arch.ServiceFactory.getAmWebPolicy(ServiceFactory.java:260) at com.sun.identity.agents.policy.AmWebPolicyManager.<init>(AmWebPolicyManager.java:44) at com.sun.identity.agents.policy.AmWebPolicyManager.<clinit>(AmWebPolicyManager.java:130) at com.sun.identity.agents.filter.URLPolicyTaskHandler.initialize(URLPolicyTaskHandler.java:63) at com.sun.identity.agents.arch.ServiceFactory.getFilterInboundTaskHandlers (ServiceFactory.java:82) at com.sun.identity.agents.filter.AmFilter.initInboundTaskHandlers(AmFilter.java:345) at com.sun.identity.agents.filter.AmFilter.initialize(AmFilter.java:80) at com.sun.identity.agents.arch.ServiceFactory.getAmFilter(ServiceFactory.java:154) at com.sun.identity.agents.filter.AmFilterManager.getAmFilter(AmFilterManager.java:60) ....more -------- [AgentException Stack] com.sun.identity.agents.arch.AgentException: Failed to initialize AmWebPolicy at com.sun.identity.agents.policy.AmWebPolicy.initialize(AmWebPolicy.java:64) at com.sun.identity.agents.arch.ServiceFactory.getAmWebPolicy(ServiceFactory.java:258) at com.sun.identity.agents.policy.AmWebPolicyManager.<init>(AmWebPolicyManager.java:44) at com.sun.identity.agents.policy.AmWebPolicyManager.<clinit>(AmWebPolicyManager.java:130) at com.sun.identity.agents.filter.URLPolicyTaskHandler.initialize(URLPolicyTaskHandler.java:63) at com.sun.identity.agents.arch.ServiceFactory.getFilterInboundTaskHandlers (ServiceFactory.java:82) at com.sun.identity.agents.filter.AmFilter.initInboundTaskHandlers(AmFilter.java:345) at com.sun.identity.agents.filter.AmFilter.initialize(AmFilter.java:80) at com.sun.identity.agents.arch.ServiceFactory.getAmFilter(ServiceFactory.java:154) at com.sun.identity.agents.filter.AmFilterManager.getAmFilter(AmFilterManager.java:60) at com.sun.identity.agents.filter.AmFilterManager.getAmFilterInstance(AmFilterManager.java:140) at com.sun.identity.agents.filter.AmAgentBaseFilter.getAmFilterInstance (AmAgentBaseFilter.java:281) at com.sun.identity.agents.filter.AmAgentBaseFilter.doFilter(AmAgentBaseFilter.java:64) ....more -------- com.sun.identity.policy.PolicyException: Cannot create application SSO token. at com.sun.identity.policy.client.PolicyEvaluator.getNewAppSSOToken(PolicyEvaluator.java:451) at com.sun.identity.policy.client.PolicyEvaluator.init(PolicyEvaluator.java:169) at com.sun.identity.policy.client.PolicyEvaluator.<init>(PolicyEvaluator.java:144) at com.sun.identity.policy.client.PolicyEvaluatorFactory.getPolicyEvaluator (PolicyEvaluatorFactory.java:130) at com.sun.identity.agents.policy.AmWebPolicy.initialize(AmWebPolicy.java:60) at com.sun.identity.agents.arch.ServiceFactory.getAmWebPolicy(ServiceFactory.java:258) at com.sun.identity.agents.policy.AmWebPolicyManager.<init>(AmWebPolicyManager.java:44) at com.sun.identity.agents.policy.AmWebPolicyManager.<clinit>(AmWebPolicyManager.java:130) at com.sun.identity.agents.filter.URLPolicyTaskHandler.initialize(URLPolicyTaskHandler.java:63) at com.sun.identity.agents.arch.ServiceFactory.getFilterInboundTaskHandlers (ServiceFactory.java:82) at com.sun.identity.agents.filter.AmFilter.initInboundTaskHandlers(AmFilter.java:345) at com.sun.identity.agents.filter.AmFilter.initialize(AmFilter.java:80) at com.sun.identity.agents.arch.ServiceFactory.getAmFilter(ServiceFactory.java:154) at com.sun.identity.agents.filter.AmFilterManager.getAmFilter(AmFilterManager.java:60) at com.sun.identity.agents.filter.AmFilterManager.getAmFilterInstance(AmFilterManager.java:140) at com.sun.identity.agents.filter.AmAgentBaseFilter.getAmFilterInstance (AmAgentBaseFilter.java:281) at com.sun.identity.agents.filter.AmAgentBaseFilter.doFilter(AmAgentBaseFilter.java:64) ....more
Symptom 4: the application server logs (in a directory like glassfish\domains\domain1\logs\server.log ) contain an error message like this:
StandardWrapperValve[default]: PWC1406: Servlet.service() for servlet default threw exception
java.lang.ExceptionInInitializerError
at com.sun.identity.agents.filter.URLPolicyTaskHandler.initialize(URLPolicyTaskHandler.java:63)
at com.sun.identity.agents.arch.ServiceFactory.getFilterInboundTaskHandlers
(ServiceFactory.java:82)
at com.sun.identity.agents.filter.AmFilter.initInboundTaskHandlers(AmFilter.java:345)
at com.sun.identity.agents.filter.AmFilter.initialize(AmFilter.java:80)
at com.sun.identity.agents.arch.ServiceFactory.getAmFilter(ServiceFactory.java:154)
at com.sun.identity.agents.filter.AmFilterManager.getAmFilter(AmFilterManager.java:60)
at com.sun.identity.agents.filter.AmFilterManager.getAmFilterInstance(AmFilterManager.java:140)
at com.sun.identity.agents.filter.AmAgentBaseFilter.getAmFilterInstance
(AmAgentBaseFilter.java:281)
at com.sun.identity.agents.filter.AmAgentBaseFilter.doFilter(AmAgentBaseFilter.java:64)
... some more stuff ....
at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
Caused by: java.lang.RuntimeException: Exception caught in AmWebPolicyManager initializer: Unable to
load IAmWebPolicy: com.sun.identity.agents.policy.AmWebPolicy
at com.sun.identity.agents.policy.AmWebPolicyManager.<clinit>(AmWebPolicyManager.java:135)
... 36 more
Symptom 5: the application server logs (in a directory like glassfish\domains\domain1\logs\server.log ) contain an NotificationServlet threw exception error message like this:
Servlet.service() for servlet NotificationServlet threw exception
java.lang.ExceptionInInitializerError
at com.sun.identity.agents.filter.URLPolicyTaskHandler.initialize(URLPolicyTaskHandler.java:63)
at com.sun.identity.agents.arch.ServiceFactory.getFilterInboundTaskHandlers(ServiceFactory.java:82)
at com.sun.identity.agents.filter.AmFilter.initInboundTaskHandlers(AmFilter.java:345)
at com.sun.identity.agents.filter.AmFilter.initialize(AmFilter.java:80)
...more
SOLUTION:
Either you need to create an agent profile on the Access Manager or you need to make your agent configuration match the agent profile name AND password.
To create an agent profile, if you previously forgot, see the agent guide section on creating a new profile. Then you will need to change your agent configuration to match this new profile name and password, which is deccribed below.
Also, if you already have an agent profile but need to change your agent configuration to have the correct current profile info, do these steps below.
To change the password used by your agent configuration:
Check the Access Manager server for the agent profile password, then on the agent use the agentadmin utility to encrypt this password and add it to the password property com.iplanet.am.service.secret in AMAgent.properties file of that agent. See the Agent guide for details on re-setting changed passwords on agents and for creating an agent profile and making a password file available to the agentadmin utility. In particular, the details in the section on using agentadmin --encrypt are helpful.
In general, you need to first stop the agent's application server domain. Then put use the correct agent profile password into a file, then run the agentadmin --encrypt command, something like this:
j2ee_agents\appserver_v9_agent\bin>agentadmin --encrypt Agent_001 somedirectory\myagentprofilepasswd.txt the proper password value in a file The encrypted value is: AQICU97UcNvQDKThciWlr7uV92/F5H2dnr62]
Then use the output value in the AMAgent.properties file property by setting its as the value of the com.iplanet.am.service.secret = AQICU97UcNvQDKThciWlr7uV92/F5H2dnr62
Then restart the application server domain.
Similarly, if you want to update the profile name you will need to:
Check the Access Manager server (maybe using console)for the correct agent profile name.
Stop the agent's application server domain.
Edit the AMAgent.properties file property by setting its as the value of the com.sun.identity.agents.app.username to the correct name of the agent profile.
Then restart the application server domain.
Access Manager Server is not available
PROBLEM:
If the Access Manager Server is down, or if you configured your agent with the wrong url, then the agent can not function correctly.
Symptom 1: You get an HTTP Status 500 error message in the browser when access an application or the agent housekeeping url( for example http://your.test.domain.com:your-agent-port-number/agentapp/)
Symptom 2: The agent debug log file amWebPolicy.log (in a directory like j2ee_agents\appserver_v9_agent\Agent_001\logs\debug)contains error messages like these :
ERROR: ApplicationSSOTokenShutdownHook.run() : failed with exception com.iplanet.sso.SSOException: Connection refused: connect at com.iplanet.sso.providers.dpro.SSOProviderImpl.destroyToken(SSOProviderImpl.java:261) at com.iplanet.sso.SSOTokenManager.destroyToken(SSOTokenManager.java:365) at com.sun.identity.agents.common.ApplicationSSOTokenProvider$ApplicationSSOTokenShutdownHook.run(ApplicationSSOTokenProvider.java:134) at java.lang.Thread.run(Thread.java:595)
Symptom 3: The agent debug log file amFilter.log (in a directory like j2ee_agents\appserver_v9_agent\Agent_001\logs\debug)contains error messages like these :
ERROR: AmFilter: a server error occurred. [AgentException Stack] com.sun.identity.agents.arch.AgentServerErrorException: No URL is available at this time at com.sun.identity.agents.common.URLFailoverHelper.getAvailableURL(URLFailoverHelper.java:119) at com.sun.identity.agents.filter.AmFilterRequestContext.getLoginURL(AmFilterRequestContext.java:762) at com.sun.identity.agents.filter.AmFilterRequestContext.getAuthRedirectURL(AmFilterRequestContext.java:263) at com.sun.identity.agents.filter.AmFilterRequestContext.getAuthRedirectURL(AmFilterRequestContext.java:237) at com.sun.identity.agents.filter.AmFilterRequestContext.getAuthRedirectResult(AmFilterRequestContext.java:342) at com.sun.identity.agents.filter.AmFilterRequestContext.getAuthRedirectResult(AmFilterRequestContext.java:325) at com.sun.identity.agents.filter.SSOTaskHandler.doSSOLogin(SSOTaskHandler.java:191) at com.sun.identity.agents.filter.SSOTaskHandler.process(SSOTaskHandler.java:79) at com.sun.identity.agents.filter.AmFilter.processTaskHandlers(AmFilter.java:172) at com.sun.identity.agents.filter.AmFilter.isAccessAllowed(AmFilter.java:135) at com.sun.identity.agents.filter.AmAgentBaseFilter.doFilter(AmAgentBaseFilter.java:66) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
Symptom 4: The agent debug log file amFilter.log (in a directory like j2ee_agents\appserver_v9_agent\Agent_001\logs\debug)contains error messages like these :
ERROR: ApplicationSSOTokenShutdownHook.run() : failed with exception com.iplanet.sso.SSOException: Connection refused: connect at com.iplanet.sso.providers.dpro.SSOProviderImpl.destroyToken(SSOProviderImpl.java:261) at com.iplanet.sso.SSOTokenManager.destroyToken(SSOTokenManager.java:365) at com.sun.identity.agents.common.ApplicationSSOTokenProvider$ApplicationSSOTokenShutdownHook.run(ApplicationSSOTokenProvider.java:134) at java.lang.Thread.run(Thread.java:595)
SOLUTION:
Make sure you have started your Access Manager server.
Or maybe make sure your agent is configured with the proper urls. At installation, the agent installer had asked you for the Access Manager Server port and host and protocol, and if you supplied the proper answers then the AMAgent.properties file would have the proper values. Or maybe you moved the server to a new url. Now you need to configure the agent with proper URL info to access the Access Manager server. One way is to un-install and then re-install your agent and provide correct info. Or you can try to modify the AMAgent.properties file yourself, which can be tricky. Roughly, go thru the AMAgent.properties file and look for any properties which have values set to an incorrect URL for Access Manager Server and edit with correct values. Some example properties are com.sun.identity.agents.config.login.url[0], some CDSSO properties if using that feature, some of the access manager service properties like com.iplanet.am.naming.url and authentication service properties like com.iplanet.am.server.host , etc. You may need to stop and restart the agent application server domain instance since some properties may not be hot swappable.
Sample Application Problems
PROBLEM:
The agent download zip contains a sample application that you can configure and deploy to learn more about using the Access manager and J2EE agents.
SOLUTION:
See the Sun Application server 9 (GlassFish) Policy Agent 2.2 Sample Application Trouble Shooting Page for a listing of trouble shooting tips when using the sample application.
Installation Fails due to use of incorrect agent version download
PROBLEM:
When you download the agent and unzip it and install it on a particular application server, the agent download must match that particular server and version. For example, if you download the agent for the Sun Application Server 8.1 but try to deploy it on the Sun Application Server 8.2. Often the installation will mostly work, but then fail on a particular step
You can also see some of these errors when you look inside the agent installation logs
For example, you might see a failure like this in the installation logs
[12/06/2007 10:42:33:758 EST] Creating a backup for file /var/opt/SUNWappserver/domains/domain1/config/domain.xml ...SUCCESSFUL. [12/06/2007 10:42:33:991 EST] Adding Agent parameters to /var/opt/SUNWappserver/domains/domain1/config/domain.xml file ...FAILED. [12/06/2007 10:56:17:908 EST] Removing Agent parameters from /var/opt/SUNWappserver/domains/domain1/config/domain.xml file ...FAILED.
SOLUTION:
It is easy to check and see if you have the right agent download for the server platform you are installing on.
- go to the bin\ diretcory of where you unzipped your agent, for example in j2ee_agents\appserver_v9_agent\bin
- run the command agentadmin --version
- see if the output of the agent version matches your platform type and platform version
Redirect Errors or loops(browser redirect error message), though user seems logged in, can see User Edit page on AM UI console
This Problem description and solution has been moved to the page of general troubleshooting tips, see http://wikis.sun.com/display/OpenSSO/J2EEAgentTrouble#J2EEAgentTrouble-redirecterrors
Add a new troubleshooting tip
PROBLEM:
SOLUTION:
Sign up or Log in to add a comment or watch this page.