Using generic templates for managed beans

[Jay Tai]

I'm wondering if there's a way to build a template for managed beans which could be extended by a constructor instead of re-writing beans for each entity. I can do that quite easily for Dao objects by creating facades and using those facades to create Dao implementations for specific entities. Not sure if the same concept works for managed beans and haven't really come accross any searches.


I wrote the following but I'm not sure how to implement or even if the concept of generics and templating can be applied to managed beans in the same way it can be applied to Dao classes:

public class BeanTemplate<T> {

    private ListDataModel<T> listModel;

    @EJB
    private GenDao dao;

    private Class<T> entityClass;

    public BeanTemplate(Class<T> entityClass) {
        this.entityClass = entityClass;
    }

    public ListDataModel<T> getListDataModel() {
        if (listModel == null) {
            listModel = makeListModel();
        }
        return listModel;
    }

    public ListDataModel<T> makeListModel() {
        List<T> tList = dao.findAll();
        ListDataModel<T> model = new ListDataModel<T>(tList);
        return model;
    }

}

The above assumes there's only one method needed in the bean. I thought of extending like this:

public class EmployeeBean extends BeanTemplate<Employee> {
public EmployeeBean() {
super(Employee.class);
}

// how can the methods be called??

Is the same concept for creating dao templates possible for managed beans? Thanks in advance

[Dieter Quickfend]

Have you tried just implementing that and making it managed?

[Jay Tai]

Yep, I get the following exception:

javax.naming.NameNotFoundException: com.manaar.module.pmtasks.dao.GenDao#com.manaar.module.pmtasks.dao.GenDao not found
	at com.sun.enterprise.naming.impl.TransientContext.doLookup(TransientContext.java:237)
	at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:204)

The class it can't find looks like this:

public abstract class GenDao<T> {

    private static final String UNIT_NAME = "MantraUserInterfaceTestPU";

    @PersistenceContext(unitName = UNIT_NAME)
    private EntityManager em;

    private Class<T> entityClass;

    public GenDao(Class<T> entityClass) {
        this.entityClass = entityClass;
    }

// Using the unchecked because JPA does not have a 
    // em.getCriteriaBuilder().createQuery()<T> method  
    @SuppressWarnings({"unchecked", "rawtypes"})
    public List<T> findAll() {
        CriteriaQuery cq = em.getCriteriaBuilder().createQuery();
        cq.select(cq.from(entityClass));
        return em.createQuery(cq).getResultList();
    }

    public void save(T entity) {
        em.persist(entity);
    }

    public void delete(T entity) {
        T entityToBeRemoved = em.merge(entity);
        em.remove(entityToBeRemoved);
    }

    public T update(T entity) {
        return em.merge(entity);
    }

    public T find(int entityId) {
       return  em.find(entityClass, entityId);
    }

// Using the unchecked because JPA does not have a 
    // ery.getSingleResult()<T> method 
    @SuppressWarnings("unchecked")
    protected T findOneResult(String namedQuery, Map<String, Object> parameters) {
        T result = null;
        try {
            Query query = em.createNamedQuery(namedQuery);
            if (parameters != null && !parameters.isEmpty()) {
                populateQueryParameters(query, parameters);
            }
            result = (T) query.getResultList();

        } catch (Exception e) {
            System.out.println("Error while running query: " + e.getMessage());
            e.printStackTrace();
        }
        return result;
    }

    public void populateQueryParameters(Query query, Map<String, Object> parameters) {
        for (Entry<String, Object> entry : parameters.entrySet()) {
            query.setParameter(entry.getKey(), entry.getValue());
        }
    }
}

I also tried to build an implementation class and implemented that:

@Stateless
public class GenDaoImpl<Employee> extends GenDao<Employee> {

    public GenDaoImpl() {
    }

    public GenDaoImpl(Class<Employee> entityClass) {
        super(entityClass);
    }
    
}

It gave me:

java.lang.IllegalArgumentException: No [EntityType] was found for the null key class parameter in the Metamodel - please specify the correct key class for the metamodel [Entity] class and verify that the key class was referenced in persistence.xml using a specific <class/> property or a global <exclude-unlisted-classes>false</exclude-unlisted-classes> element.

[Tim Holloway]

I'm a little wary of attempting to "template-ize" JSF because the JSF architecture is designed with most of the really important template-like functions already built in.

But your example is certainly a reasonable one.

The reason it fails, however, isn't because it's JSF. I'm pretty sure that the EJB annotations aren't being inherited by the subclasses. Annotations can be defined as inheritable or non-inheritable, so they have to be used with care.

[Jay Tai]

It would sure save a heck of a lot of tedious grunt work if thre's a way i could template managed beans. Especially if they all involve the same old CRUD operations. I guess my question would be how I would make inherently non-inheritable EJBs inherited by the sub class. I was also wary, but the DAOs template with little problems and work perfectly. I guess there must be a way to extend the really important template functions where managed beans are concerned or maybe i'm missing some key limitations in the JSF architecture.

[Tim Holloway]

The main limitation is that JSF is basic POJO. It does not support constructors with arguments in them. About as close as you can get is to inject in an argument-constructed property object, like something Spring could build, but the actual JSF managed bean mechanism can only invoke a no-arguments constructor.

One trick I use in situations like these is to make an abstract base class with an abstract accessor method. So, for example:

abstract protected T getMyEJB();

This forces the subclasses to include code maybe something like this:

@EJB
private T myEJB;

protected T getMyEJB() {
   return myEJB;
}

Somewhat kludgy, but better than nothing.

[Jay Tai]

I'm trying to avoid Spring which looks like it has a big learning curve and expensive configuration overheads. I think I see where you're going with your abstract class. I'm still thinking about how to adapt that to a managed bean. I'll post the results. Meanwhile I'd be interested to know if you've ever managed to apply that to a managed bean succesfully did CDI with EJBs. Thank you!

[Tim Holloway]

This is the kind of code I would put into a template-based Managed Bean. Actually, I think have.

The core Spring is (or was) only about 150K. Problem is, usually a lot of secondary Spring subsystems end up moving in.

On the plus side, they move in because they're so darned useful. They make it easy to work with plug-replaceable components, handle the grunt wrappers around persistence code (such as getting and releasing JDBC Connections with proper allowances for Exceptions, and so on.

I looked at CDI in depth about 2 months ago and was disappointed. It's like Spring but missing some of Spring's capabilities and there didn't seem to be as much effort made into making Spring legacy code easily transition into it as I'd like.

I'm already at JBoss for making JBoss 4 upgrades equivalent to the VB-to-VB.Net transition without having further breakages to deal with.

[Jay Tai]

I'm certainly much less of a veteran when it comes to different java flavors. I figure JSF is key if only for the learning experience. I intend to keep things as POJO as possible till I'm more fluent. But I'm curious, is spring really an xml file configuration nightmare? Obviously one drawback with JSF is the tedious repition required to build generic classes. Here I think your abstract template could be a life saver. But I'm really curious about diving into Spring

[Tim Holloway]

Spring and JSF both started out using XML, but in both cases, XML now is the last-resort (override) mechanism, with annotations generally preferred.

For example, to define a DAO in Spring, you'd create a POJO class and annotate it with the Spring @Repository marker. You'd probably also annotate it as @Transactional.

To inject it into a JSF backing bean, you'd use the @ManagedBean annotation and an EL expression, since as long as faces-config wired in the Spring/JSF expression bridge, Spring beans and JSF beans would appear indistinguishable in the EL namespace.

The Manning Press "Spring in Action" book has what I think is a pretty good hit-the-ground-fast introduction.

Spring objects are POJO. That's the whole point of Spring. To be able to take POJOs and wire them together, just as JSF takes POJOs (backing beans) and wires then together. The only reason I combine both in my webapps is that JSF's bean management is specific to backing beans and no-argument constructors, but Spring can take generic beans and has the option to use argument-based constructors and/or factories. It doesn't, however attempt to replace JSF's bean management or processing lifecycle features, so the two are more complementary than exclusive.

[Jay Tai]

The fact that Spring and JSF are complimentary and Spring is suited for building generic beans is music to my ears. The choice I have now is either to try and implement your abstract class and continue and entirely JSF app or to try combing it with a Spring configuration for building some of my generic beans. I know this may sound like an open ended question but do you think it would be realistic to be up and running with at least one or two generic bean classes in a matter of weeks following the book you suggested?

[Tim Holloway]

Well, if my memory isn't playing tricks again, I've got at least one JSF app using an inheritable base class on Managed Beans whose persistence service is an injected Spring object.

Backing beans are not Spring beans, since JSF manufactures them directly, as needed without using Spring. However, ManagedProperties are set via EL expressions and those expressions can reference either JSF-managed or Spring-managed beans as long as you have the EL bridge setup in faces-config.xml.