InfoCenter Home >
8: Problem determination >
8.7: Using application level facilities
8.7: Using application level facilities
WebSphere Application Server Standard 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 file on developing applications.
Tools that are specifically designed to debug application, servlet and EJB problems include OLT
and Distributed Debugger.
Typical application and EJB problems are:
- Invoking a servlet from a browser window
- 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 webapp
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.
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 is set to true.
Follow these steps to check the setting of the Auto Reload property:
- From the WebSphere Administration Console, select your application (or default_app if you stored
your servlets in the default directory structure).
- From the Web Application:default_app panel, select the Advanced tab.
- Verify that the Auto Reload is set to true.
WebSphere Application Server makes JDBC calls, using a predefined JDBC driver, to communicate
with a database. Both the JDBC driver and datasources must be configured using the administrative console.
The following errors occur if a datasource 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:
- An invalid JDBC driver 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 EJBs. 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 EJBs
EJB's can be classified as:
- Session beans - extensions of client applications without persistence
- Entity beans - a type of BMP (Bean Managed Persistence) where implementer manages persistence
- Entity beans - a type of CMP (Container Managed Persistence) where framework manages persistence
See tbe file about writing enterprise beans, for a description of EJB components and
functions.
A summary of EJB 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
- Use the jetace.bat file on Windows NT or jetace.sh on UNIX to run the
JETACE tool (com.ibm.ejb.jetjar.JetAceMain) in line mode
- The output jar file is the EJB jar file that you will deploy in the WebSphere Administrative
Console.
- The EJB jar file will contain your EJB classes and a deployment descriptor (.ser) file.
- If your EJBs use JNI (Java Native Interface), loaded libraries should be added to:
- Path on Windows NT
- Whatever is defined for the LD_LIBRARY_PATH property in file startupServer.sh on UNIX
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 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 EJB jar file on
a server.
- When you experience the error, java.lang.NoClassDefFoundError: myejbHome,
add the client EJB jar file to the client classpath.
|
|