InfoCenter Home >
8: Problem determination >
8.7: Using application level facilities
8.7: Using application level facilities
WebSphere Application Server, Advanced Single Server Edition only supports Web applications, not
enterprise beans. WebSphere Application Server,
Advanced Edition supports both Web applications and enterprise
beans.
For more information on enterprise beans and Web applications,
see the article about developing applications.
Tools that are specifically designed to debug application, servlet and enterprise bean problems include OLT
and Distributed Debugger. OLT provides an object level trace.
The Distributed Debugger allows you to set trace points in your code.
Typical application and enterprise bean problems are:
- A modified servlet is not reloaded
- Incorrectly using of databases as a session store
- Various exceptions running enterprise beans
The following example describes what you should enter in a browser window to
invoke a servlet. Errors occur when you fail to include the Web application
directory in the path.
http://server_machine/webapp/examples/showCfg
The components of the URL are:
server_machine |
webapp |
examples |
showCfg |
Name of the application server computer |
Virtual directory of the Web application loader.
Do not create a webapp directory. This directory is defined for you by WebSphere Application Server.
For more information on webapp, see the file on the programming model and environment. |
Application Web path
This is a default WebSphere servlet Web path.
You can create a directory by any name as long as it is defined in the Web application's
category. |
Servlet URL, not the name of the code.
In this example, the actual Servlet class name is
ServletEngineConfigDumper. |
The URL illustrated above is the URL for showCfg, one of the default servlets shipped with WebSphere
Application Server.
A servlet might not show up in a browser for the following reasons:
- The servlet was not configured
- The servlet is within an application server that is not started
- The servlet is configured, but the corresponding class is missing
- The host alias part of the URI is not defined as the virtual host
In earlier versions of WebSphere Application Server, specific reload directories in the reload process
had to be defined. Currently, the only reload requirement is to store servlet classes
in the Web application category. That is, ensure all your servlets are
handled in the context of the Web application loader. After you update your servlets, the Web
application loader will automatically reload them for you.
If your servlet classes are installed in the context of the Web application loader, but
are not being reloaded, ensure the Auto Reload property in the Web module properties
is set to true.
WebSphere Application Server makes JDBC calls, using a predefined JDBC provider, to communicate
with a database. Both the JDBC provider and data sources must be configured using the administrative console.
The following errors occur if a data source is misconfigured or does not exist:
- The browser window displays Error 500 with the message: java.lang.NullPointerException
- The <App_Server>.stderr.log displays the message: javax.naming.NameNotFoundException: jdbc/xxx
- The <App_Server>.stdout.log displays the message: Failure while creating connection COM.ibm.db2.jdbc.app.DB2Exception: [IBM] [CLI Driver] SQL1013N
The database alias name or database name "SAMPLE" could not be found. SQLSTATE=42705
Database connectivity problems cause persistence exceptions. An
EJSPersistenceException error may indicate JDBC or connection problems:
- Ensure that the database driver (such as, db2java.zip or classes111.zip) are on the
administrative server classpath with the current path and file name.
- An invalid JDBC provider will prevent access to JAR and class files
- Review the SQLSTATE:
COM.ibm.db2.jdbc.app.DB2Exception: [IBM][CLI Driver]
SQL1224N A database agent could not be started...
SQLSTATE=55032...
The SQLSTATE code of 55032 indicates the system is out of connections.
Note: Not using connection pooling causes most problems
for BMP type enterprise beans. Common symptoms include:
- Performance problems connecting to the database
- Running out of connections
To resolve the problem:
- Increase the number of connections permitted by DB2 or Oracle.
- On AIX, catalog the database as if it were remote.
- Ensure you close connections when programming exceptions occur.
- Verify that connections obtained in one method,
are returned to the pool via close().
- Verify that your application does not try to access pre-empted connections (idle connections
that are now used by other resources).
- A database init failure could indicate the database does not exist:
com.ibm.ejs.persistence.EJSPersistenceException: Database init failure:
Nested exception is:
COM.ibm.db2.jdbc.app.DB2Exception: [IBM][CLI Driver]
SQL1013N The database alias name or database name "YYY" could not be found...
SQLSTATE=42705...
The SQLSTATE code of 42705 indicates the database does not exist or the server cannot
connect to it.
Various exceptions running enterprise beans
See the InfoCenter article about how enterprise beans are classified for a description of the different types of
enterprise beans.
See the InfoCenter article about writing enterprise beans for a description of enterprise bean components and
functions.
A summary of enterprise bean failures
- If you modify a bean and then see the following exception:
java.io.InvalidClassException: xpackage.xBean;
Local class not compatible: stream classdesc serialVersionUID=54545...
Local class serialVersionUID=589090...
the deployment descriptor (also known as the serialized descriptor) is missing and must be recreated.
To recreate the deployment descriptor follow these steps:
- Run the JETACE tool from the GUI or in line mode
- The output JAR file is the enterprise bean JAR file that you will deploy in the WebSphere administrative
console.
- The enterprise bean JAR file will contain your enterprise bean classes and a deployment descriptor (.ser) file.
- If your enterprise beans use JNI (Java Native Interface), see article 6.4.1 for guidelines.
Missing libraries will cause the following error:
java.lang.UnsatisfiedLinkError: no <missing DLL> in shared library path
at java.lang.Runtime.loadLibrary(Runtime.java:440)
at java.lang.System.loadLibrary(System.java:569)
You must stop and restart the server after the problem is resolved.
- If your client application or servlet fails during operation,
JNDI ctxt.lookup("myinterface")
review the generated exception:
- When you experience the exception, Cannot instantiate class:com.ibm.ejs.ns.jndi.CNnitialContextFactory,
the classpath is incorrect. Add ibmwebas, EJS and UJC and JAR files and retry.
- When you experience the exception, COMM_FAILURE, verify the administrative server host is running and
accessible by entering the command: telnet <host> 900
If telnet fails, either the host is not listening on port 900 or a firewall is not permitting
the connection (check the filters settings in the firewall).
If telnet hangs, the connection is successful, but a stale home reference is left over in the
name space; that is, no server implemented that bean. Redeploy the enterprise bean JAR file on
a server.
- When you experience the error, java.lang.NoClassDefFoundError: myejbHome,
add the client enterprise bean JAR file to the client classpath.
|
|