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

Invoking a servlet by its URL

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

Reloading servlets

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.

Incorrect configuration of a data source

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
  1. 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:

    1. Run the JETACE tool from the GUI or in line mode
    2. The output JAR file is the enterprise bean JAR file that you will deploy in the WebSphere administrative console.
    3. The enterprise bean JAR file will contain your enterprise bean classes and a deployment descriptor (.ser) file.
  2. If your enterprise beans use JNI (Java Native Interface), see article 6.4.1 for guidelines.
  3. 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.

  4. 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.


Go to previous article: Diagnosing Configuration and Installation Problems Go to next article: ORB-related Minor Codes

 

 
Go to previous article: Diagnosing Configuration and Installation Problems Go to next article: ORB-related Minor Codes