This Troubleshooting Guide addresses common difficulties you may encounter when installing and using the Application Server. It contains the following sections:
Note:
Check the Known Bugs section of the Release Notes for additional issues.
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 java.net.BindException 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 java.net.BindException 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 java.net.BindException:
Address already in use: <port_number>
Diagnostics:
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.
asadmin start-domain domain1
This message is actually comes from Application Server 7. The full message looks like either
Could not start the domain. There are no domains.
or
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.
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:
<install_dir>/domains/domain1/logs/
In addition to these log files, the SetupSDK framework creates default low-level installation and uninstallation log files at the following locations:
/var/sadm/install/logs/Sun_ONE_Application_Server_install
/var/sadm/in __TBD__
The location and content of these files is defined externally within the SetupSDK framework.
Diagnostics:
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:
install_dir/domains/domain1/logs/server.log
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 .]
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:
install_dir/domains/domain1/config/domain.xml
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:
When you visit the start page of the Application Server, the initial screen does not appear.
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:
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?.
You should be able to access the server directly from your local system (localhost) as follows (for the default port 8080):
http://localhost: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:
http://myhost.mydomain.com:8080/
To find your hostname and domain:
The Admin Console provides an interface for administrative functions. If you cannot access the Admin Console, consider the following questions.
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.
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.
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:
<jvm-option>-Djava.security.policy=yourPolicy</jvm-option>
That line must be present to access the Admin Console.
If you are unable to access a particular application, consider the solutions in this section.
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.
An application must be successfully deployed before it can be accessed.
Check the server's log file here:
install_dir/domains/domain1/server.log
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.
AS_ADMIN_USER=admin
AS_ADMIN_PASSWORD=administrator
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):
<install_dir>/lib/install/applications/adminapp/adminapp_war/WEB-INF
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.
asadmin create-file-user --user <dummy> --password <dummy>
--userpassword <new_secret> --groups asadmin <new_user_id>
This command creates a new entry here:
<install_dir>/domains/domain1/config/keyfile.
Note:
When the server is started, any remote command-line operations will need new_user_id and new_secret as user name and password.
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.
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.
Use the asadmin stop-domain command to stop the server, or explicitly kill the Java process, then restart the Application Server.
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.
To use the new J2SE for all domains, change the AS_JAVA variable in asenv.conf (Solaris/Linux), or asenv.bat (Windows).
Note:
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.
A more time-intensive solution is to deinstall and then reinstall the installation.
An application generates a com.sun.jdo.api.persistence.support.JDODataStoreException 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.
The following error occurs from an application client or in the server.log:
java.security.AccessControlException: 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";
};
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:
[...INFO|sun-appserver-pe8.0|javax.enterprise.system.container.ejb|...|
javax.ejb.AccessLocalException: Client not authorized for this invocation.
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:...
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.
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.
This failure can occur when the keystore and trustore properties are not set properly.
Set the following properties on the JVM:
javax.net.ssl.keyStore=<keystore-file-path>;javax.net.ssl.trustStore=<truststore-file-path>
To use the application client, set the environment variable VMARGS to the following value:
-Djavax.net.ssl.keyStore=${admin.domain.dir}/${admin.domain}/config/keystore.jks
-Djavax.net.ssl.trustStore=${admin.domain.dir}/${admin.domain}/config/cacerts.jks
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".
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).
Set the java debugging property on the JVM. To see the handshake information from the application client, append -Djavax.net.debug=ssl,handshake to the VMARGS variable.
Yes. The server lets you change the password to the keystore using the following J2SE properties:
-Djavax.net.ssl.keyStorePassword=password
-Djavax.net.ssl.trustStorePassword=password
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.