Adapter for Enterprise JavaBeans 6.5 SP3 | webMethods Adapter for Enterprise JavaBeans Documentation | webMethods Adapter for Enterprise JavaBeans Installation and User’s Documentation | Adapter Logging and Exception Handling | Adapter Exception Handling
 
Adapter Exception Handling
 
AdapterException
AdapterConnectionException
AdapterServiceException
Reporting Non-Fatal Connection Errors
Adapter for Enterprise Javabeans throws three exception classes that you should be aware of as you build integrations using the adapter: AdapterException, AdapterConnectionException, and AdapterServiceException. In all cases, the adapter passes the underlying exception on to the Adapter Runtime, which wraps it in a container exception that it then passes on to Integration Server. Integration Server then serializes the exception and returns it to the client service. Typically, that client (for example, a flow or Java service that calls an adapter service) will include logic that traps these exceptions and branches accordingly. For information about how to trap the exception in a flow, see the webMethods Service Development Help for your release.
With Adapter for Enterprise Javabeans, errors typically originate from one of two sources: JNDI or EJB:
*JNDI exceptions generally are manifested as instances of javax.naming.NamingException. This is simply a generalized wrapper for a list of low-level causes; some fatal, some not. Adapter for Enterprise Javabeans examines the NamingException object to determine the underlying cause, and then wraps it in either an AdapterException or an AdapterConnectionException. If the exception occurs during lookup or introspection of a specific EJB, the adapter throws the wrapped exception to the Adapter Runtime. If the exception occurs while the adapter is while navigating the JNDI tree, the adapter logs a message in the Server log at level 8 (Verbose4) and continues.
*EJB exceptions are typically wrapped as java.rmi.RemoteException. As with NamingExceptions, Adapter for Enterprise Javabeans examines it for the root cause, wraps it in an AdapterException or AdapterConnectionException, and throws it to the Adapter Runtime.