+

Search Tips   |   Advanced Search

Enterprise bean cannot be accessed from a servlet, a JSP file, a stand-alone program, or another client

Use these troubleshooting tips for problems related to accessing enterprise beans.

What error did you encounter?

If the client is remote to the enterprise bean, which means, running in a different application server or as a stand-alone client, browse the JVM logs of the application server hosting the enterprise bean, as well as log files of the client.

(zos) If the client is remote to the enterprise bean, which means, running in a different application server or as a stand-alone client, browse the logs of the application server hosting the enterprise bean, as well as log files of the client.

If we do not see a problem that resembles yours, or if the information provided does not solve the problem, perform these steps:

  1. If the problem appears to be name-service related, which means that you see a NameNotFoundException error, or a message ID beginning with NMSV, see these topics for more information:

  2. Check to see if the problem is identified and documented using the links in Diagnosing and fixing problems: Resources for learning.
If we still cannot fix the problem, see Troubleshooting help from IBM for further assistance.


java.lang.NoSuchMethodError

When trying to invoke a method on a Session Bean, a java.lang.NoSuchMethodError occurred.

The following is an example of this type of error:

When trying to invoke the method xSLTStory4Session on a bean, a java.lang.NoSuchMethodError displayed.
 CNTR0020E: EJB threw an unexpected (non-declared) exception during invocation of method "xSLTStory4Session"  on bean "BeanId(ERWW_v8#XSLTStory4SessionEJB3.jar#XSLTStory4SessionFacadeBean, null)".  Exception data: java.lang.NoSuchMethodError: paysession/ejb3/PaySessionFacadeRemote.
paySession(Ljava/lang/String;)Ljava/lang/String;

In this case, there are multiple versions of the PaySessionFacadeRemote interface in multiple modules within the EAR file. One of the interfaces does not contain the expected method.

The stub class was generated by the run time from the first version of the PaySessionFacadeRemote interface in the class path of the EAR file which was the incorrect version.


ObjectNotFoundException or ObjectNotFoundLocalException when accessing stateful session EJB

A possible cause of this problem is that the stateful session bean timed out and was removed by the container. This event must be addressed in the code, according to the EJB 2.1 and later specification. We can review the EJB 2.1 and 3.0 specifications at http://java.sun.com/products/ejb/docs.html.


Stack trace beginning "EJSContainer E Bean method threw exception [exception_name]" found in JVM log file

If the exception name indicates an exception thrown by an IBM class that begins with "com.ibm...", then search for the exception name within the information center, and in the online help as described. If "exception name" indicates an exception thrown by the application, contact the application developer to determine the cause.


javax.naming.NameNotFoundException: Name name not found in context "local"

A possible reason for this exception is that the enterprise bean is not local (not running in the same JVM [JVM] or application server) to the client JSP, servlet, Java application, or other enterprise bean, yet the call is to a "local" interface method of the enterprise bean . If access worked in a development environment but not when deployed to WebSphere Application Server, for example, it might be that the enterprise bean and its client were in the same JVM in development, but are in separate processes after deployment.

To resolve this problem, contact the developer of the enterprise bean and determine whether the client call is to a method in the local interface for the enterprise bean. If so, have the client code changed to call a remote interface method, or to promote the local method into the remote interface.

References to enterprise beans with local interfaces are bound in a name space local to the server process with the URL scheme of local:. To obtain a dump of a server local: name space, use the name space dump utility described in the article " Namespace dump utility for java:, local: and server namespaces".


BeanNotReentrantException is thrown

This problem can occur because client code, typically a servlet or JSP file, is attempting to call the same stateful SessionBean from two different client threads. This situation often results when an application stores the reference to the stateful session bean in a static variable, uses a global (static) JSP variable to refer to the stateful SessionBean reference, or stores the stateful SessionBean reference in the HTTP session object. The application then has the client browser issue a new request to the servlet or JSP file before the previous request has completed.

To resolve this problem, ask the developer of the client code to review the code for these conditions.


CSITransactionRolledbackException / TransactionRolledbackException is thrown

An enterprise bean container creates these high-level exceptions to indicate that an enterprise bean call did not complete. When this exception is thrown, browse the JVM logs to determine the underlying cause.

(zos) An enterprise bean container creates these high-level exceptions to indicate that an enterprise bean call did not complete. When this exception is thrown, browse the logs to determine the underlying cause.

Some possible causes include:


Attempt to start EJB module fails with "javax.naming.NameNotFoundException dataSourceName_CMP" exception

This problem can occur because:


Transaction [tran ID] has timed out after 120 seconds accessing an enterprise bean

This error can occur when a client executes a transaction on a CMP or BMP enterprise bean.


(zos) Message BBOT0003W is issued

Message BBOT0003W indicates a transaction timeout. The timeout might result in the abnormal termination of the servant where the transaction is running.


Symptom:CNTR0001W: A Stateful SessionBean could not be passivated

This error can occur when a Connection object used in the bean is not closed or nulled out.

To confirm this is the problem, look for an exception stack in the JVM log for the EJB container that hosts the enterprise bean, and looks similar to:

[time EDT] <ThreadID> StatefulPassi W CNTR0001W:  A Stateful SessionBean could not be passivated: StatefulBeanO
(BeanId(XXX#YYY.jar#ZZZZ, <ThreadID>),  state = PASSIVATING) com.ibm.ejs.container.passivator.StatefulPassivator@<ThreadID>
java.io.NotSerializableException: com.ibm.ws.rsadapter.jdbc.WSJdbcConnection   at java.io.ObjectOutputStream.outputObject((Compiled Code))   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Compiled Code))   at java.io.ObjectOutputStream.outputClassFields((Compiled Code))   at java.io.ObjectOutputStream.defaultWriteObject((Compiled Code))   at java.io.ObjectOutputStream.outputObject((Compiled Code))   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Compiled Code))   at com.ibm.ejs.container.passivator.StatefulPassivator.passivate((Compiled Code))    at com.ibm.ejs.container.StatefulBeanO.passivate((Compiled Code)   at com.ibm.ejs.container.activator.StatefulASActivationStrategy.atUnitOfWorkEnd
                      ((Compiled Code))   at com.ibm.ejs.container.activator.Activator.unitOfWorkEnd((Compiled Code))   at com.ibm.ejs.container.ContainerAS.afterCompletion((Compiled Code)
where XXX,YYY,ZZZ is the bean name, and <ThreadID> is the thread ID for that run.

(zos) To confirm this is the problem, look for an exception stack in the logs for the EJB container that hosts the enterprise bean, and looks similar to:

StatefulPassi W CNTR0001W:  A Stateful SessionBean could not be passivated: StatefulBeanO
(BeanId(XXX#YYY.jar#ZZZZ),  state = PASSIVATING)  java.io.NotSerializableException: com.ibm.ws.rsadapter.jdbc.WSJdbcConnection   at java.io.ObjectOutputStream.outputObject((Compiled Code))   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Compiled Code))   at java.io.ObjectOutputStream.outputClassFields((Compiled Code))   at java.io.ObjectOutputStream.defaultWriteObject((Compiled Code))   at java.io.ObjectOutputStream.outputObject((Compiled Code))   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Compiled Code))   at com.ibm.ejs.container.passivator.StatefulPassivator.passivate((Compiled Code))    at com.ibm.ejs.container.StatefulBeanO.passivate((Compiled Code)   at com.ibm.ejs.container.activator.StatefulASActivationStrategy.atUnitOfWorkEnd
                      ((Compiled Code))   at com.ibm.ejs.container.activator.Activator.unitOfWorkEnd((Compiled Code))   at com.ibm.ejs.container.ContainerAS.afterCompletion((Compiled Code)
where XXX,YYY,ZZZ is the bean name.

To correct this problem, the application must close all connections and set the reference to null for all connections. Typically this activity is done in the ejbPassivate() method of the bean. Also, note that the bean must have code to reacquire these connections when the bean is reactivated. Otherwise, there are NullPointerExceptions when the application tries to reuse the connections.


Symptom: org.omg.CORBA.BAD_PARAM: Servant is not of the expected type. minor code: 4942F21E completed: No

This error can be returned to a client program when the program attempts to execute an EJB method.

Typically this problem is caused by a mismatch between the interface definition and implementation of the client and server installations.

Another possible cause is when an application server is set up to use a single class loading scheme. If an application is uninstalled while the application server remains active, the classes of the uninstalled application are still loaded in the application server. If we change the application, redeploy and reinstall it on the application server, the previously loaded classes become back level. The back level classes cause a code version mismatch between the client and the server.

To correct this problem:

  1. Change the application server class loading scheme to multiple.

  2. Stop and restart the application server and try the operation again.

  3. Make sure the client and server code version are the same.


Related tasks

  • Assembling EJB modules