Use EJB just as a Wrapper

Discussions

EJB design: Use EJB just as a Wrapper

  1. Use EJB just as a Wrapper (3 messages)

    Is this a good idea to put all the business logics in a regular business java class and then use a stateless EJB just as a warp and delegate all the requests to the business class just for the reason that maybe someday this business class will be reused in a none ejb environment.

    Threaded Messages (3)

  2. Use EJB just as a Wrapper[ Go to top ]

    Another reason using the EJB as a wrapper is a good idea is you can reuse the logic in the regular java classes with other EJB's. Using an EJB as a wrapper allows you more flexability to modularize code.
  3. Use EJB just as a Wrapper[ Go to top ]

    I have a problem where 5 different stateless session beans share common logic. What I have done is it put this common logic in an abstract Java class and then have the SBs extend from this class.
    The abstract class looks like this:

    public abstract class CommonClass extends SessionBean {
        public SessionContext ejbContext;
        
        public void ejbCreate() {
        }
        
        public void ejbActivate() {
        }
        
        public void ejbPassivate() {
        }
        
        public void ejbRemove() {
        }
        
        public void setSessionContext(SessionContext ctx) {
            ejbContext = ctx;
        }
        
        public SessionContext getEJBContext() {
            return ejbContext;
        }

        //common methods
        public void commonMethod() {
        ....
        ....
        }
    }

    If the common method has some transactional logic, would it be managed by the EJB container?
  4. Use EJB just as a Wrapper[ Go to top ]

    If the common method has some transactional logic, would >it be managed by the EJB container?


    Yes -- the EJB container doesn't care what other classes get called.

    If the call to the EJB implementation class started a transaction, any DB connection you get via the EJB server's connection pool will be part of this transaction, unless you call another EJB which has REQUIRES_NEW etc. set.

    Tom