Sun Java™ System Application Server PE 8 Troubleshooting Guide

This Troubleshooting Guide addresses common difficulties you may encounter when installing and using the Application Server. It contains the following sections:

Known Bugs

Check the Known Bugs section of the Release Notes for additional issues.

Compilation errors appear in the server log

After starting the server, an examination of server.log shows multiple compilation errors, of the form

Fatal Error from EJB Compiler -- Compilation failed: ...

This problem appears in Windows systems when double quotes exist in the path. One known source of double quotes is Norton Ghost. When installed double quotes appear around its part of the path. Removing the double quotes makes the compilations succeed.

A occurs when you attempt to associate an HTTP listener with more than one virtual server.

SJSAS PE 8.0 does not run when an HTTP listener is associated with more than one virtual server in domain.xml. It is possible to do so using Admin Console while the server is running, but a occurs when you attempt to restart, indicating that the HTTP listener's port is already in use, and this error message is logged:

Error initializing endpoint
Address already in use: <port_number>

Common Problems

asadmin start-domain command fails


Error: "CLI143 There is more than one domain..."

When issued with no arguments, the command asadmin start-domain fails with the error,

CLI143 There is more than one domain in C:\Sun\AppServer\domains. 
Please use operand to specify the domain.
CLI156 Could not start the domain null.

This error occurs when there is more than one domain in the domains directory, none of them is named domain1, and no domain is specified in the start-domain command.


Specify the domain when issuing the start-domain command, like this:
asadmin start-domain domain1

Error: "Could Not Start Domain"

This message is actually comes from Application Server 7. The full message looks like either

Could not start the domain. 
There are no domains.


Could not start the domain. 
No default domain.  Need to enter a domain. 

This error occurs when App Server 7 is installed on the same system, and its asadmin command (at /usr/sbin) is found on the path before the asadmin command for App Server 8 at <install>/bin. The situation is especially likely to occur on Solaris/Linux systems when "." is not specified as part of the PATH variable because, without that setting, the asadmin command in /usr/sbin is found on the path, even when the current directory is <install>/bin.


Make sure that /opt/SUNWappserver/bin is on the path ahead of /usr/sbin or that "." is on the path ahead of /usr/sbin if you will be accessing asadmin by changing directories to /opt/SUNWappserver/bin.

Can't find log files

The following Application Server logs can be useful for troubleshooting problems you may have with installation:

Both the installation and uninstallation programs create log files and log all installation and uninstallation events to these files. The primary purpose of these log files is to provide troubleshooting information.

In addition to installation program messages and log files, operating system utilities such as pkginfo and showrev on Solaris and rpm on Linux can be used to gather system information.

Log file entries include information about the attempted action, the outcome of the action, and, if applicable, the cause of failure. The log files contain the following types of message entries:

The application server logs are located in the following directory:


In addition to these log files, the SetupSDK framework creates default low-level installation and uninstallation log files at the following locations:

/var/sadm/in __TBD__

The location and content of these files is defined externally within the SetupSDK framework.

Accessing local server fails (for example, http://localhost:8080)


Did the server start?

If the console window is still open, it should display a message like this:

Domain domain1 Started

where domain1 is the name of the default domain. This indicates that the default domain was started successfully.

If you have already closed the console window, you can check for messages in the log file here:


If startup was successful, you should see a message similar to this at the end of the log file:

[INFO][...][..][date&time][Application server startup complete .]

Was the server started at the expected port?

The server could be running at a different port number than the one you expect, either because it was intentionally installed there, or because another server was already running on the default port when the server was installed.

To determine which port number the server is actually using:

  1. Examine the server's configuration file here:
  3. Find the http-listener element.

  4. Inspect the value of the port attribute.

Be sure to enter the correct port number when invoking the server.

How the expected port number can change

The server's default port number is 8080, however, there are a number of ways in which the expected value can change:

Acessing remote server fails

When you visit the start page of the Application Server, the initial screen does not appear.

Is the server available locally?

If the server cannot be accessed from the web, but it is running locally, then the server is actually running.

To verify that the server is running locally:

  1. Log on to the machine where the server is running.

  2. Visit the local web page. For example:

    http://localhost:8080/ (where 8080 is the default port)

If the start page does appear, there is a problem with the web connection that prevents accessing the server remotely. If the start page does not appear, see Did the Server Start?.

Is your proxy setting causing a problem?

You should be able to access the server directly from your local system (localhost) as follows (for the default port 8080):


You may not be able to access your local system if your browser connects to the web through a proxy. (A proxy is a program that looks like a direct web connection, but which is actually a separate program that makes that connection for you.) To solve this problem, do one of the following:

Can't access the Admin Console

The Admin Console provides an interface for administrative functions. If you cannot access the Admin Console, consider the following questions.

Is the Application Server running?

The server must be running before the Admin Console can be accessed. Review the information in Did the Server Start? to determine if the server is running.

Is the Admin Console running at the expected port?

The default port number for the Admin Console is 4848. However, it could be running at a different port number than the one you expect, either because it was intentionally installed there, or because that port was taken when the server was started.

Refer to "Was the server started at the expected port?" for guidelines on checking the port your Admin Console is actually running on.

Be sure to enter the correct port number when invoking the Admin Console.

Is the Security Manager enabled?

According to the J2EE 1.4 specification, the Security Manager is not optional. It must be enabled in the Application Server. Since there is no configuration interface that lets you disable the Security Manager, it can only happen by modifying the domain.xml configuration file in such a way that you remove this line:


That line must be present to access the Admin Console.

Can't access a server application

If you are unable to access a particular application, consider the solutions in this section.

Is the Application Server running?

Review the information in Did the Server Start? to determine if the server is running. The server must be running before a server application can be accessed.

Was application deployment successful?

An application must be successfully deployed before it can be accessed.

Check the server's log file here:


Invalid user or password, supposed to be automatic

You're getting the error, "Invalid user or password", but you installed the system with the "Don't Prompt" option, so the password should be supplied automatically.

Is the correct password being supplied?

To check, inspect the .asadminprefs file. On Unix systems, it's in your home directory. On Windows, it's in C:\Documents and Settings\<username>. It's contents look something like this:


Admin user name or password not known

If you have forgotten the admin user name, you can find it by inspecting the .adminprefs file, as described in the section above, or by inspecting the <install_dir>/domains/domain1/config/keyfile, where domain1 is the default domain. (For a different domain, substitute it's name in the path.)

If you have forgotten the administrator password, you'll need to create a new user name-password pair by removing the user name and password, creating new ones, and restarting the server. (You won't be able to read the password, because it's encrypted in the keyfile.)

To remove the user name and password completely (resetting the user name and password to nothing):

  1. Stop the server, if it is currently running.
  2. Access the following:
  4. Comment out the entire <security-constraint> element in the web.xml file. (Don't delete it. You'll be reenabling it later).
    This action disables security for command-line operations.

Note The commands will still expect a value for --username or -u and --password or -w. But these can be any dummy values, since the server side does not impose any security.

  1. Start the server. At this point, the server does not have command-line security.
  2. Run the following command:
    asadmin create-file-user --user <dummy> --password <dummy> 
            --userpassword <new_secret> --groups asadmin <new_user_id>

    This command creates a new entry here:

  4. Uncomment the <security-constraint> element in web.xml file.

  5. Restart the server for the new user name-password to take effect.

    When the server is started, any remote command-line operations will need new_user_id and new_secret as user name and password.

Server won't start on Windows (port conflict)

If you get a message similar to the following when you try to start the Application Server on Microsoft Windows, a server port conflict has occurred:

Address already in use

This happens because another application is running on the Application Server port (default 8080), or because a previously-running Application Server did not shut down cleanly.

Is another application running on the server's port?

If another application is using the server's port, stop the other application, then restart the Application Server.

Explanation of why the next available port is not used—Generally the installer chooses the next available port if the default port is in use, but this only works if the application using the default port is running at the time the Application Server is installed.

Has an ungraceful shutdown occurred on a previously-running server?

Use the asadmin stop-domain command to stop the server, or explicitly kill the Java process, then restart the Application Server.

Error: "System cannot find the path specified"

This error message occurs when attempting to start the server after deleting the J2SE directory that was specified during installation. This situation generally occurs after being informed during the install that the J2SE platform needs an upgrade, and the upgrade takes place after the app server install.

Solution 1

To use the new J2SE for all domains, change the AS_JAVA variable in asenv.conf (Solaris/Linux), or asenv.bat (Windows).

You can also use change the J2SE version used by a particular domain by modifying domain.xml to change the setting of the java-config element's java-home attribute.

Solution 2

A more time-intensive solution is to deinstall and then reinstall the installation.

An application generates a with a nested java.sql.SQLException indicating a duplicate primary key.

Even if the application is checking for a CreateException, it does not see one. The Enterprise JavaBeans specification requires a CreateException to be thrown only if two beans with the same primary key are created in the same transaction, so a CreateException is not thrown on transaction rollback if two entity beans with duplicate primary keys are created.


If an application might create an entity bean with a duplicate primary key, check to see if the primary key exists by calling findByPrimaryKey before calling create.

Security Issues access denied

The following error occurs from an application client or in the server.log: access denied (java.util.PropertyPermission name write...

There is a permissions issue in the policy files. Either the client.policy for the application client or the server.policy for server side components does not have permission to set the property. Add the permission in client.policy (for the application client), or in server.policy (for ejb/web modules) for the application that needs to set the property.. By default, applications only have "read" permission for properties.

For example, to grant read/write permission for all the files in the codebase directory, add or append the following to client.policy or server.policy:

grant codeBase "file:/.../build/sparc_SunOS/sec/-" { 
  permission java.util.PropertyPermission "*", "read,write"; 

javax.ejb.AccessLocalException: Client not authorized

Role-mapping information is available in Sun-specific XML (for example, sun-ejb-jar.xml), and authentication is ok, but the following error message occurs:

     javax.ejb.AccessLocalException: Client not authorized for this invocation. 
         at com.sun.ejb.containers.BaseContainer.preInvoke( 
        at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(...)

Check whether the ejb module (.jar) or web module (.war)  is packaged in an application (.ear) and doesn't have role-mapping information in application level, Sun-specific, sun-application.xml. For any application (.ear), security role-mapping information must be specified in sun-application.xml. It is ok to have both module-level XML and application-level XML.

Authentication is not happening with the Solaris Realm

Check whether the installation and server startup was performed as a local user, instead of as the root user. You must be the root user when starting the appserver, instead of a local user, because the Solaris realm works only with the root user. It wasn't designed to work with any other local user. Note, too, that role mapping can happen on the local user.

Mutual authentication not working with the application client

This failure can occur when the keystore and trustore properties are not set properly.

Set the following properties on the JVM:<keystore-file-path>;<truststore-file-path> 

To use the application client, set the environment variable VMARGS to the following value:${admin.domain.dir}/${admin.domain}/config/keystore.jks${admin.domain.dir}/${admin.domain}/config/cacerts.jks

Frequently Asked Questions

What happens when no server side realm is configured?

When the application is configured (within XML files), but no server side realm is configured, the application is authenticated in the default realm. No error is thrown that indicates "No such realm".

Can I use PKCS12 certificate for my client certificate?

Is there a way to use my PKCS12 certificate for an SSL the application client or standalone client during mutual authentication?

No. One can't use PKCS12 certificate directly, but  you can write your own client using the JSSE, which supports storetype=PKCS12 (read only, no write to keystore).

How to see the TLS/SSL handshake information during SSL client?

Set the java debugging property on the JVM. To see the handshake information from the application client, append,handshake to the VMARGS variable.

Can I change the keystore password?

Yes. The server lets you change the password to the keystore using the following J2SE properties:

Note that the keystore password must match the individual key passwords to perform operations on the keys, so you will need to change the keystore password with the property mentioned above and then change the password to each key to match that password.