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.

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.

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?

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