Hi - I was curious as to the thinking behind having a SessionBean interface for both stateful/stateless session beans? If you DID have the two seperate interfaces it would change things. For stateless: - No need for the programmer to create a home interface as we know that you will just want a create() method The container could create the home interface for you. This would force a convention of some sort (FooHome). Could always do a "if there isn't one..." I guess containers could implement this now, it just would restrict portability. - No need for ejbPassivate()/ejbActivate() You wouldn't need "Stateful" or "Stateless" to be placed into the deployment descriptors. Having to tell the container the type seems more error prone.... don't we want the code to be coupled strongly to the type? Has anyone used this loose coupling to help out in an application? It's late and maybe I am missing something :) Dion ps. I am also "for" having different entity bean methods (ejbRemove() for session/entity beans are very different) _____________________________________________________________ Dion Almaer | [EMAIL PROTECTED] | voice: 720.304.3244 CustomWare | http://www.customware.com | fax: 360.242.0671 =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
