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.

since the adapter usually comes to make concrete classes easier, it is usually not used directly, but mostly subclassed by concrete classes.
Thus it makes more sense to make the adapter an abstract class.

I have tried to implement the Adaptor as Abstract, but container is not allowing the Bean as Abstract.

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.

Yes, you are right. I have tried in WLS 5.1 with EJB 1.1 specs.

Alternative view point: Super Class for all session bean
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