Sun Java System Access Manager 7.1 Developer's Guide

Utility APIs

The utilities package is called It contains utility programs that can be used by external applications accessing Access Manager. Following is a summary of the utility API and their functions.


This class contains the methods used to retrieve the TopLevelAdmin DN and password. The information comes from the server configuration file, serverconfig.xml, located in AccessManager-base/SUNWam/config/ums.


The AMClientDetector interface executes the Client Detection Class configured in the Client Detection Service to get the client type.


The AMPasswordUtil interface has two purposes:


The Debug utility allows an interface to file debug and exception information in a uniform format. It supports different levels of information (in the ascending order): OFF, ERROR, WARNING, MESSAGE and ON. A given debug level is enabled if it is set to at least that level. For example, if the debug state is ERROR, only errors will be filed. If the debug state is WARNING, only errors and warnings will be filed. If the debug state is MESSAGE, everything will be filed. MESSAGE and ON are the same level except MESSAGE writes to a file, whereas ON writes to System.out.

Note –

Debugging is an intensive operation and can hurt performance. Java evaluates the arguments to message() and warning() even when debugging is turned off. It is recommended that the debug state be checked before invoking any message() or warning() methods to avoid unnecessary argument evaluation and maximize application performance.


This class is a utility that provides the functionality for applications and services to internationalize their messages.


This class provides functionality that allows single-point-of-access to all related system properties. First, the class tries to find AMConfig.class, and then a file,, in the CLASSPATH accessible to this code. The class takes precedence over the flat file. If multiple servers are running, each may have their own configuration file. The naming convention for such scenarios is AMConfig_serverName.


ThreadPool is a generic thread pool that manages and recycles threads instead of creating them when a task needs to be run on a different thread. Thread pooling saves the virtual machine the work of creating new threads for every short-lived task. In addition, it minimizes the overhead associated with getting a thread started and cleaning it up after it dies. By creating a pool of threads, a single thread from the pool can be reused any number of times for different tasks. This reduces response time because a thread is already constructed and started and is simply waiting for its next task.

Another characteristic of this thread pool is that it is fixed in size at the time of construction. All the threads are started, and then each goes into a wait state until a task is assigned to it. If all the threads in the pool are currently assigned a task, the pool is empty and new requests (tasks) will have to wait before being scheduled to run. This is a way to put an upper bound on the amount of resources any pool can use up. In the future, this class may be enhanced to provide support growing the size of the pool at runtime to facilitate dynamic tuning.