Sun Java System Access Manager Policy Agent 2.2 Release Notes

All J2EE Agents in Policy Agent 2.2

The following known issues exist that affect all J2EE agents in Policy Agent 2.2.

A harmless error message appears in the J2EE agent log files (6301668)

This error message, which appears in certain situations, is as follows: ERROR: RemoteHandler.getLogHostURL(): 'null' is malformed. null.

Workaround: You can ignore this message.

The agentadmin --install command displays an error message after being issued a second time (6268136)

The error message displayed in this situation is as follows:

*** ERROR: Another instance of agentadmin is already running. Please stop
that instance and try again.

This message appears when the first installation operation is aborted with the CTRL-z keystroke combination. This keystroke combination suspends the process, but does not actually stop the process. If other methods are used to abort the operation, such as the CTRL-c keystroke combination, this problem does not occur.

Workaround: When this problem is encountered, close the terminal window and open a new terminal window.

Resources accessed with Internet Explorer 6.0 SP1 can result in 404 Not Found Error (6362249)

This problem occurs when the following conditions apply:

This specific configuration results in an error message primarily because of a bug in Internet Explorer 6.0 SP1, which cannot properly handle redirection when the HTTP request contains a port number. More specifically, this browser does not update the host header to reflect the new port number when you redirect HTTP requests that contain a port number.

Workaround: If the browser used to access content protected by a J2EE agent is Internet Explorer, at a minimum, the version must be Internet Explorer 6.0 SP2.

Harmless error messages related to JAX-RPC appear in the J2EE agent debug files (6325238)

In the J2EE agent debug files, you might see exceptions related to Java API for XML-based remote procedure calls (JAX-RPC). Such messages are not an indication of any known problem.

Workaround: You can safely ignore these error messages.

Exceptions thrown when Access Manager uses polling with a J2EE agent (6452320)

Errors can occur when you perform both of the following:

  1. Deploy amclientsdk.jar file on a client machine, such as when deploying a J2EE agent.

  2. Enable polling in Access Manager.

The errors that appear are similar to the following:

ERROR: Send Polling Error: amSessionPoller thread pool's task queue 
is full.

Workaround: This workaround is specific to J2EE agents. If you deployed Access Manager Client SDK in another manner, such as by deploying the Distributed Authentication UI, the two properties mentioned subsequently would be added to the Access Manager configuration file instead of to the J2EE agent configuration file.

If you have only a few hundred concurrent sessions, you can create the following properties in the J2EE agent configuration file by adding the two following lines to the bottom of the file:


For thousands or tens of thousands of sessions, the values should be set the same as those for notification in the Access Manager file after running amtune-identity.

For example, for a machine with 4GB of RAM, the Access Manager amtune-identity will set the following:


You can set similar values in the J2EE agent configuration file when the machine for the J2EE agent has 4GB of RAM:


Policy Agent 2.2 guides do not explain configuration of J2EE Agents and Access Manager SDK on the Same Deployment Container

Currently, no information is provided in Policy Agent 2.2 documentation for J2EE agents regarding this issue. Therefore, the required task for this scenario is presented at this time in this document.

If you install a J2EE agent instance on the same deployment container (such as an application server) as an Access Manager SDK instance, you must edit a property in the file of the Access Manager SDK instance.

This task is necessary to ensure proper evaluation of policies. The configuration task described in this section applies to J2EE agents, not web agents, in the Policy Agent 2.2 software set. Therefore, no additional configuration steps are required when an Access Manager SDK instance and a web agent instance are installed on the same deployment container (such as a web server).

Note –

The configuration task described in this section applies to situations where Access Manager SDK was installed as a separate component using the Sun Java Enterprise System installer. The configuration task described in this section is not required for the following versions of the SDK:

ProcedureTo Install a J2EE Agent Instance With an Access Manager SDK Instance

This task is performed on the deployment container on which the Access Manager SDK is installed. This same deployment container is protected by the J2EE agent.

  1. Using an editor of your choice access the Access Manager SDK file.

  2. Edit the following property as shown

    com.sun.identity.agents.config.location = PolicyAgent-base/AgentInstance-Dir/config/
  3. Save and close the file.

  4. Restart the deployment container.

J2EE agent installation prompts do not allow responses with leading or trailing spaces (6452708)

The installer for J2EE agents does not ignore leading and trailing spaces when you provide answers to prompts. This situation can cause a variety of problems. For example, if you include a leading or trailing space when pointing to a resource, the resource would not be recognized and an error message such as the following would be issued:

ERROR: Invalid Server Instance directory.

The preceding error message is one example. Any one of several messages could be issued depending upon the specific scenario.

Workaround: None. However, be aware of the situation and be sure not to include leading or trailing spaces when providing responses to installation prompts.

The agentadmin --install command fails to install the J2EE agent because of a previous unsuccessful installation (6443460)

An agent instance directory, for example agent_001, is created early in a J2EE agent installation. If that installation is unsuccessful, then the actual agent “agent_001” is not created, but the directory agent_001 might have been created. If the agent instance directory was created, the installer does not remove it in cases where the installation fails. In such a scenario, a subsequent installation attempt of a J2EE agent would fail unless the directory agent_001 is manually removed first.

In this scenario, the installer does not detect the previously unsuccessful installation of agent_001. and, therefore, attempts to create it. At first, the installer only searches for the agent instance, not the agent instance directory. As the installation begins, the installer attempts to create the agent_001 directory, but at that point the installer finds that this directory already exists. The installer then aborts the installation. In such a scenario, an error message such as the following is issued:

ERROR: Installation failed due to the following error - (Failed to
create directory /export/j2ee_agents/am_websphere_agent/agent_001.)

Workaround: Manually remove the agent instance directory of the unsuccessful agent installation before attempting to install the agent again.

The first use of a resource protected by a declarative constraint results in a misdirect

At this time, this behavior affects all J2EE agents except for the various agents for BEA WebLogic and Apache Tomcat.

This situation occurs prior to the user being authenticated by Access Manager and only when web-tier declarative security is set for the specific resource the user is attempting to access. Under these circumstances, when the user attempts to access the resource, she (after authentication) is directed to the welcome page of the application instead of to the exact location requested.

While the user might not expect to be directed to the welcome page, the result does not constitute an access problem. From the welcome page, the user can still access the desired resource based on the policies defined.

Workaround: This behavior is expected. No workaround exists.

The agentadmin --getUuid command fails for amadmin user on Access Manager 7 with various agents (6452713)

When you issue the agentadmin --getUuid command to retrieve the universal ID of the amadmin user, you might see an error message such as the following:

agentadmin --getUuid amadmin user example
Failed to create debug directory
Failed to create debug directory
Failed to create debug directory
Failed to create debug directory
Failed to create debug directory
10/25/2006 02:22:39:834 PM PDT: Thread[main,5,main]
DataLayer: number of retry = 3

The problem occurs under these conditions:

Workaround: None at this time.