0 Replies Latest reply on Apr 18, 2011 5:36 PM by Anton Lisovenko

    Stateful EJB is created on each injection

    Anton Lisovenko Newbie


      I use GF 3.1 and embedded Weld (1.1). I have the view scoped CDI bean which inherits the abstract class, which dynamically injects the necessary EJB bean:


          public AbstractBean(GenericProducer genericProducer) {        
              this.dao = genericProducer.findOutDao(getClass());


      public class GenericProducer {
          Instance<AbstractDAO<Persistable>> daoInstance;
          public <T extends Persistable> AbstractDAO<T> findOutDao(Class clazz) {
              // Getting the qualifier of the class
              if (clazz != null) {
                  Annotation qualifier = findOutEntityType(clazz);
                  if (qualifier == null) {
                      log.error("No qualifier is found for the class {}!", clazz.getName());
                      return null;
                  AbstractDAO<T> result = (AbstractDAO<T>) daoInstance.select(qualifier).get();
                  return result;
              return null;


      public abstract class AbstractDAO<T extends Persistable> implements Serializable {
          EntityManager em;
      // All dao methods here

      Here is the example of such DAO, which is automatically injected to the UI bean:

      public class PolisDAO extends AbstractDAO<Polis> {

      And now the main problem. Each invocation dynamic invocation of daoInstance.select(qualifier).get(); returns the new instance of DAO. Also the interesting moment: I enabled the EJB monitoring in GF 3.1 (server-config - monitoring), I see the statistics for my PolisDAO. The main frustrating thing is the NumBeansInCache parameter, which grows on each page refresh or postback! This seems, that the Stateful session bean is recreated on each injection!

      I faced several issues with inheritance of EJBs in GF 3.0 (some are left in 3.1) - can this be reasoned by this?

      I'm going to move to stateless EJB, but anyway would like to know, why each injection creates the new instance of SFSB...