[EJB3] Stateless Session Bean & Inheritance

[antonio each]

Hi all

I'm developing a web application with: JSF,EJB3 and JPA (without DAO Layer).

So the idea is to create a FATHER ABSTRACT SESSION BEAN which expose all principal CRUD commons operation such as INSERT,REFRESH,DELETE ENTITY etc:

@Local
public interface AbstracLocalBaseServices{
  void insert();
  void refresh();
  ....
}

@Stateless
public abstract class AbstractBaseService implements AbstractLocalBaseServices{

  //here implementation of local interface methods
  ...
  ... 
  ...


} 

So each SPECIALIZED SESSION EJB needs to extends this AbstractBaseService.

@Local
public interface SpecializedLocalService{

   void specializedMethodA();
   void specializedMethodB();
   ....
   ....

}

@Stateless
public class SpecializedService extends AbstractBaseService implements SpecializedLocalService{
    
   //specialized method's interface implementation
   .... 
   ....
} 

Ok...This is what we have tryed ,but WEBLOGIC application server fails to run:
Reading ejb3 specification on sun site i have understood why:

Specification says:
"A Session Bean class annotated with @Stateless can't be ABSTRACT and can't INHERIT from another @Stateless session bean"

My answer is:

Is there a way to accomplish my goal?

I thought:

and if i don't declare my AbstractBaseService as @Stateless session bean....???
What happen to @Stateless session bean which extends it?

Any help is appreciate!

Antonio

[Victor Herrera]

Hi, you can safely remove the Stateless annotation in the abstract class. Inheritance will provide you with the functionality of the parent class but it doesn't need to be an EJB. For the parent interface you can remove Local annotation too.

Think that the the abstract base service can not be a working component by their own.

[Nico Van Brandt]

That is true.

You cannot define a bean abstract or final because the container needs full control of them.
But because beans are like POJOs you are supposed to inherit from other POJOs.

[antonio each]

Thank you for clear explanation!

I confirm all what you have posted here and I'm very happy for the architecture of my application!

Antonio

[Piotr Nowicki]

Antonio, could you tell me how did you access the EntityManager from your non-EJB superclass (AbstractBaseService)? Or maybe you didn't use the EntityManager for these CRUD operations?

Cheers!

[Jaikiran Pai]

Pedro Kowalski wrote:Antonio, could you tell me how did you access the EntityManager from your non-EJB superclass (AbstractBaseService)? Or maybe you didn't use the EntityManager for these CRUD operations?

Cheers!

1) If the base class is abstract he won't be able to create an instance of that. So accessing from the base class in that case is ruled out. i.e. you'll need to lookup the bean which extends that class and then let that bean instance access the injected entitymanager.

2) If the base class is not abstract and itself is a bean and also has a subclass which is a bean, then there are 2 bean implementation classes. The user can lookup either of them separately and use the injected entity manager.

[antonio each]

Jaikiran Pai wrote:

Pedro Kowalski wrote:Antonio, could you tell me how did you access the EntityManager from your non-EJB superclass (AbstractBaseService)? Or maybe you didn't use the EntityManager for these CRUD operations?

Cheers!

1) If the base class is abstract he won't be able to create an instance of that. So accessing from the base class in that case is ruled out. i.e. you'll need to lookup the bean which extends that class and then let that bean instance access the injected entitymanager.

2) If the base class is not abstract and itself is a bean and also has a subclass which is a bean, then there are 2 bean implementation classes. The user can lookup either of them separately and use the injected entity manager.

Hi Pedro, The point 1 of jakiran post is the way:
the BASE bean is abstract,so it never can be instantiated! Each bean which extends base class retrieve an instance of entity manager to perform operations with db.

Bye

[Piotr Nowicki]

Thanks Jaikiran and Antonio!

I didn't know that EJB's let you do so gnarly stuff! So, take a look at this example:

public interface GenericCrud<T extends Serializable>  {
	Serializable create(T t);

	void delete(T t);
}

public abstract class GenericCrudBean<T extends Serializable> implements GenericCrud<T> {

	@PersistenceContext
	private EntityManager em;

	@Override
	public T create(T t) {
		System.out.println(this.getClass().getName() + " create TEST! " + em);
		return null;
	}

	@Override
	public void delete(T t) {
		System.out.println(this.getClass().getName() + " delete TEST! " + em);
	}
}

public interface ConcreteService extends GenericCrud<MyEntity> {
	void businessMethod();
}

@Stateless
@Local(ConcreteService.class)
public class ConcreteServiceBean extends GenericCrudBean<MyEntity> implements ConcreteService {

	@PersistenceContext
	private EntityManager em;

	@Override
	public void businessMethod() {
		System.out.println("Concrete service business method test! " + em);
	}

}

So, right now in my code I can use:

@EJB
ConcreteService m;

And invoke all CRUD operations and business methods - all with CRUD operations implementation reusing.

Is this approach valid, or does it have any flaws? The EntityManager in each of these fields is the same object, so I guess it's fine, right?

By the way - I'm really suprised that the EJB container will inject EntityManager into GenericCrudBean's private field even if it's not annotated as EJB. Really nice!

Cheers and thanks in advace!

[Christian Gosch]

Look at the quote below, comments on EntityManager declarations are added by me:

Piotr Nowicki wrote:

public abstract class GenericCrudBean<T extends Serializable> implements GenericCrud<T> {

	@PersistenceContext
	private EntityManager em; // generic instance, so to say: Necessary for generic operations

	@Override
	public T create(T t) {
		System.out.println(this.getClass().getName() + " create TEST! " + em);
		return null;
	}

	@Override
	public void delete(T t) {
		System.out.println(this.getClass().getName() + " delete TEST! " + em);
	}
}

public interface ConcreteService extends GenericCrud<MyEntity> {
	void businessMethod();
}

@Stateless
@Local(ConcreteService.class)
public class ConcreteServiceBean extends GenericCrudBean<MyEntity> implements ConcreteService {

	@PersistenceContext
	private EntityManager em; // concrete instance, so to say 
	// overwriting the generic one? 
	// Necessary as "annotation attach point"? 
	// What happens if this instance variable is NOT declared, thus reusing the generic declaration?

	@Override
	public void businessMethod() {
		System.out.println("Concrete service business method test! " + em);
	}

}

I wonder if the "concrete EM" declared in ConcreteServiceBean is necessary!

What happens if no EM is declared in ConcreteServiceBean ? The EM declared in GenericCrudBean should be visible also here?

Thanks for useful answers (because this "architecture" fully matches what I am doing also :-) )