Network Deployment (Distributed operating systems), v8.0 > Migration and coexistence > Migrate EJB applications > Migrate enterprise bean code to the supported specification

Adjust exception handling for EJB wrapped applications migrating from version 5 to version 7

Because of a change in the Java APIs for XML based Remote Procedure Call (JAX-RPC) specification, EJB applications that could be wrapped in WAS v5.1 cannot be wrapped in version 6 or 7 unless you modify the code to the exception handling of the base EJB application.

Essentially, the JAX-RPC version 1.1 specification states:

a service specific exception declared in a remote method signature must be a
checked exception. It must extend java.lang.Exception either directly or indirectly
but it must not be a RuntimeException.

So it is no longer possible to directly use java.lang.Exception or java.lang.Throwable types. We must modify the applications using service specific exceptions to comply with the specification.

Procedure

1. Modify the applications that use service specific exceptions. For example, say that your existing EJB uses a service specific exception called UserException. Inside of UserException is a field called ex that is type java.lang.Exception.

   To successfully wrapper the application with web services in WAS version 7, change the UserException class . In this example, you could modify UserException to make the type of ex to be java.lang.String instead of java.lang.Exception.

   new UserException class:
   
   package irwwbase;
   
   /**
    * Insert the type's description here.
    * Creation date: (9/25/00 2:25:18 PM)
    * @author: Administrator
    */
   
   
   public class UserException extends java.lang.Exception {
   
          private java.lang.String _infostring = null;
          private java.lang.String ex;
   /**
    * UserException constructor comment.
    */
   
   public UserException() {
          super();
   }
   /**
    * UserException constructor comment.
    */
   public UserException (String infostring)
   {
          _infostring = infostring;
   } // ctor
   /**
    * Insert the method's description here.
    * Creation date: (11/29/2001 9:25:50 AM)
    * @param msg java.lang.String
    * @param ex java.lang.Exception
    */
   public UserException(String msg,String t) {
          super(msg);
          this.setEx(t);
   
          }
          /**
           * @return
           */
          public java.lang.String get_infostring() {
                 return _infostring;
          }
   
          /**
           * @return
           */
          public java.lang.String getEx() {
                 return ex;
          }
   
          /**
           * @param string
           */
          public void set_infostring(java.lang.String string) {
                 _infostring = string;
          }
   
          /**
           * @param Exception
           */
          public void setEx(java.lang.String exception) {
                 ex = exception;
          }
   
          public void printStackTrace(java.io.PrintWriter s) {
            .println("the exception is :"+ex);
            }
   
   }
   

2. Modify all of the exception handling in the enterprise beans that use it. We must ensure that your enterprise beans are coded to accept the new exceptions. In this example, the code might look like this:

   new EJB exception handling:
   
   try {
         if (isDistributed()) itemCMPEntity = itemCMPEntityHome.findByPrimaryKey(ckey);
         else itemCMPEntityLocal = itemCMPEntityLocalHome.findByPrimaryKey(ckey);
     } catch (Exception ex) {
          .println("%%%%% ERROR: getItemInstance - CMPjdbc " + _className);
          ex.printStackTrace();
          throw new UserException("error on itemCMPEntityHome.findByPrimaryKey(ckey)",ex.getMessage());
   
   

+

Search Tips   |   Advanced Search