text: The pattern is about creating SessionAdapter,EntityAdapter and MessageAdapter classes.For example the SessionAdapter could look something like this:
  public class SessionAdapter implements SessionBean {
  protected SessionContext sc;
  ....... All methods of the SessionBean interface
  }//End of SessionAdapter
  public class XSessionBean extends SessionAdapter {
  .... Business methods & Overridden methods
  }//End of XSessionBean
  This would eliminate the need to type all the methods much similar to the Adapter classes found in the AWT package of Java and override methods of interest.
  Incase the Bean extends some custom value object then this adapter pattern cannot be applied.
  Adapter Pattern (5 messages)
  - Posted by: Kumaraguruparan Karuppasamy
  - Posted on: January 14 2003 05:59 EST
  Threaded Messages (5)
  - adapters are usually abstract classes by Nir Sharony on January 14 2003 12:03 EST
  - Adapter Pattern by vimarsh vasavada on January 03 2004 01:01 EST
  adapters are usually abstract classes[ Go to top ]
  since the adapter usually comes to make concrete classes easier, it is usually not used directly, but mostly subclassed by concrete classes.
  - Posted by: Nir Sharony
  - Posted on: January 14 2003 12:03 EST
  - in response to Kumaraguruparan Karuppasamy
  Thus it makes more sense to make the adapter an abstract class.
  adaptor cannot be a Abstract[ Go to top ]
  I have tried to implement the Adaptor as Abstract, but container is not allowing the Bean as Abstract.
  - Posted by: vasa a
  - Posted on: January 31 2003 08:01 EST
  - in response to Nir Sharony
  Problems?[ Go to top ]
  You should not have any problems creating an Adaptor as abtract. I've done it using WLS 6.1 and the container doesn't complain.
  - Posted by: SAF .
  - Posted on: April 29 2003 16:34 EDT
  - in response to vasa a
  Problems[ Go to top ]
  Yes, you are right. I have tried in WLS 5.1 with EJB 1.1 specs.
  - Posted by: vasa a
  - Posted on: May 08 2003 04:26 EDT
  - in response to SAF .
  Adapter Pattern[ Go to top ]
  Alternative view point: Super Class for all session bean
  - Posted by: vimarsh vasavada
  - Posted on: January 03 2004 01:01 EST
  - in response to Kumaraguruparan Karuppasamy
  All SessionBeans extends SuperSessionBean[Abstract is fine]
  The SuperBean can centralize implementation for all common-services required by all session beans.For eg debug/log/lookup etc.
  All Remote interface extends SuperRemote
  The remote can centralize certain common service made available by all components to all clients.For example
  Services meant for other generalized components like Search
  - search(String entityName,List criterialist)
  - getEntityPage(String entityName)
  to support strategy pattern for business rule validation
  - getValidator()
  - getValidator(RequestInfo ri)
  to support command engine interface
  -executeCommand(Command cmd)
  Participate in my thread :
  Single Home Interface for All Session Bean
  vim