Subclassing rules for Session beans

[Joe San]

For example, I have a Local interface as,

@Local
public interface MyBean { 
 String myMethod () {}
}

And the implementation class which is a stateless bean like,

@stateful
public class SuperClass implements MyBean {
 //implementation for the myMethod goes here...
}

@stateless
public class SubClass extends SuperClass implements MyBean{
 //implementation for myMethod goes here...
}

Can anyone explain me on the Annotation inheritance?

[nitin pai]

It won't work. As per the specifications, you cannot inherit from a superclass which itself is a session bean.
[ June 14, 2008: Message edited by: nitin pai ]

[Joe San]

From the specs...is ok but I read in the book EJB 3 in Action on Subclassing rules for Session beans?? Here is what it says...

A session bean class can subclass another session bean or any other POJO.
For example, a stateless session bean named BidManager can extend
another session bean PlaceBidBean in the following way:
@Stateless
public BidManagerBean extends PlaceBidBean implements BidManager {
...
}

[nitin pai]

Quoting from the spec section 4.6.2, 6th point in "Optionally"

The session bean class may have superclasses and/or superinterfaces. If the session bean has
superclasses, the business methods, lifecycle callback interceptor methods, the timeout callback
method, the methods of the optional SessionSynchronization interface, the
Init or ejbCreate<METHOD> methods, the Remove methods, and the methods of the
SessionBean interface, may be defined in the session bean class, or in any of its superclasses.
A session bean class must not have a superclass that is itself a session bean class.

Books can have mistakes, but certification will be based on specification.

[Joe San]

Originally posted by nitin pai:
Quoting from the spec section 4.6.2, 6th point in "Optionally"



Books can have mistakes, but certification will be based on specification.

Thanks Nitin. Any reason why we can't have a session bean as another session bean's superclass?

[nitin pai]

It may be possible that your session bean is stateless and you unknowingly extend it with a session bean which is stateful. The behavior of your application will be weird then, don't you think so?

[Christophe Verré]

I tried this on Glassfish :

@Remote
public interface SimpleBean { 
public String sayHello(String name);
}
 
@Stateless(name="Example", mappedName="ejb/SimpleBeanJNDI") 
public class SimpleBeanImpl implements SimpleBean {
@PersistenceContext(name="my_persistence_ctx")
EntityManager em;

public String sayHello(String name) {
return "Hello " + name + "! "; 
}
}
 
@Remote
public interface OtherBean [B]extends SimpleBean[/B] {
public void doSomething();
}
 
@Stateless(name="OtherBean", mappedName="ejb/OtherBeanJNDI")
public class OtherBeanImpl [B]extends SimpleBeanImpl implements OtherBean[/B] {
 
public void doSomething() {
System.out.println("DoSomething");
}
}

The client :

OtherBean otherbean = (OtherBean) ctx.lookup("ejb/OtherBeanJNDI");
otherbean.doSomething();
// Accessing parent's method
hello = otherbean.sayHello("Chris");
System.out.println(hello);

It's funny that it worked

[Joe San]

So Nitin, did the specs go wrong?

[nitin pai]

Originally posted by Jothi Shankar Kumar Sankararaj:
So Nitin, did the specs go wrong?

Do you even know what specs means?

[Joe San]

Originally posted by nitin pai:


Do you even know what specs means?

I know what specs mean...I doubt you practically know anything as it looks like you just follow something that's written somewhere (like specs) and then just post it here in the ranch as though you tried it.

[Joe San]

Originally posted by Christophe Verre:
I tried this on Glassfish :

@Remote
public interface SimpleBean { 
public String sayHello(String name);
}
 
@Stateless(name="Example", mappedName="ejb/SimpleBeanJNDI") 
public class SimpleBeanImpl implements SimpleBean {
@PersistenceContext(name="my_persistence_ctx")
EntityManager em;

public String sayHello(String name) {
return "Hello " + name + "! "; 
}
}
 
@Remote
public interface OtherBean [B]extends SimpleBean[/B] {
public void doSomething();
}
 
@Stateless(name="OtherBean", mappedName="ejb/OtherBeanJNDI")
public class OtherBeanImpl [B]extends SimpleBeanImpl implements OtherBean[/B] {
 
public void doSomething() {
System.out.println("DoSomething");
}
}

The client :

OtherBean otherbean = (OtherBean) ctx.lookup("ejb/OtherBeanJNDI");
otherbean.doSomething();
// Accessing parent's method
hello = otherbean.sayHello("Chris");
System.out.println(hello);

It's funny that it worked

Any takers on this?

[Sergio Tridente]

Hi Jothi,

I am with nitin on this one: the specification is the law. You'll be asked about the specification, not any particular implementation (not even the reference implemetation).

However, just out of curiosity, what happens when you try this?

@Remote
public interface SimpleBean { 
public String sayHello(String name);
}
 
@Stateless(name="Example", mappedName="ejb/SimpleBeanJNDI") 
public class SimpleBeanImpl implements SimpleBean {
@PersistenceContext(name="my_persistence_ctx")
EntityManager em;

public String sayHello(String name) {
return "Hello " + name + " from SimpleBean ! "; 
}
}
 
@Remote
public interface OtherBean extends SimpleBean {
public void doSomething();
}
 
@Stateless(name="OtherBean", mappedName="ejb/OtherBeanJNDI")
public class OtherBeanImpl extends SimpleBeanImpl implements OtherBean {
 
public void doSomething() {
System.out.println("DoSomething");
}

public String sayHello(String name) {
return "Hello " + name + " from OtherBean ! "; 
}
}

In the client:

SimpleBean simplebean = (SimpleBean) ctx.lookup("ejb/SimpleBeanJNDI");
simplebean.doSomething();
// Accessing parent's method
hello = simplebean.sayHello("Chris");
System.out.println(hello);

Please, post results. :-)

[Christophe Verré]

Don't be fooled by my sample. I only mean that the book said that it would work because they may have tried it on a container supporting it, but the specs are the specs. If they tell that it does not work, then it doesn't. If it does, it's container specific and should not be relied on.

[Christophe Verré]

SimpleBean simplebean = (SimpleBean) ctx.lookup("ejb/SimpleBeanJNDI");
simplebean.doSomething();

Sergio, in your example, how would you call doSomething on a SimpleBean ?

[Sergio Tridente]

Originally posted by Christophe Verre:

SimpleBean simplebean = (SimpleBean) ctx.lookup("ejb/SimpleBeanJNDI");
simplebean.doSomething();

Sergio, in your example, how would you call doSomething on a SimpleBean ?

Sorry. My mistake. I meant something like:

SimpleBean simplebean = (SimpleBean) ctx.lookup("ejb/SimpleBeanJNDI");
hello = simplebean.sayHello("Chris");
System.out.println(hello);

[Joe San]

I know that specs is like E=mc^2 for Java/J2EE technologies. But from the lines what nitin has posted mentioning the specs, I thought that there would be a mention somthing like..."It is up to the container vendors...." so is our case similiar to that? As per the specs, a session bean cannot subclass another session bean but it is up to the vendors to make subclassing session bean possible.
[ June 27, 2008: Message edited by: Jothi Shankar Kumar Sankararaj ]

[Jaikiran Pai]

Originally posted by Jothi Shankar Kumar Sankararaj:
I thought that there would be a mention somthing like..."It is up to the container vendors...." so is our case similiar to that? As per the specs, a session bean cannot subclass another session bean but it is up to the vendors to make subclassing session bean possible.

Jothi,

You are right, in some cases the specs leave it to the vendors to decide how they deal with certain things. But in this case the spec states that:

A session bean class must not have a superclass that is itself a session bean class.

So if Glassfish is allowing the superclass itself to be a session bean, then i would say that its a bug in Glassfish server, since its not following the specs.

[Joe San]

Originally posted by Jaikiran Pai:


So if Glassfish is allowing the superclass itself to be a session bean, then i would say that its a bug in Glassfish server, since its not following the specs.

Thanks and I was thinking in the same lines.

[sanjeev mehra]

Jothi Shankar Kumar

From the specs...is ok but I read in the book EJB 3 in Action on Subclassing rules for Session beans?? Here is what it says...

quote:A session bean class can subclass another session bean or any other POJO.
For example, a stateless session bean named BidManager can extend
another session bean PlaceBidBean in the following way:
@Stateless
public BidManagerBean extends PlaceBidBean implements BidManager {
...
}

Same book (EJB 3 In Action) also says that if parent is a bean then bean annotation is not inherited; but call back (life cycle) annotation, business methods,.... are inherited from parent class.



nitin pai

A session bean class must not have a superclass that is itself a session bean class.

As per spec, parent must not be a bean (session bean), isn't it compile time issue (compiler is allowing to have bean parent)?

[Joe San]

Interestingly there is a similiar discussion in the Head First EJB book in the chapter for Session Beans (Page 186) which I found to be worth mentioning here.

[Jaikiran Pai]

As per spec, parent must not be a bean (session bean), isn't it compile time issue (compiler is allowing to have bean parent)?

Its not a compile time issue. From a Java compiler's perspective, its perfectly valid for one class to extend another. Java compiler has no knowledge of what EJBs are. Its the application server which at deployment time takes care of ensuring that the EJBs follow the specs.

[sanjeev mehra]

In other case, basic rule is a class can not 2 classes;
and if a class extends 2 classes, compiler throws error message.

Are both rules (EJB - SB bean must not extend another SB & a POJO class must not extends 2 POJO classes) comes in to different categories? So that first is okay for compiler but not the second.

[Vinay Nath]

sanjeev, Both are wrong, you cannot have multiple inheritance in Java.

What he was saying is that compiler will have no problem because all session beans are just normal classes to compiler and One class can Extend another class without a problem.

Its only a question of container whether it allows a class which is a session bean to extend another class which is also a session bean, and specs says that is illegal.

[sanjeev mehra]

thanks for reply.
for compiler @Stateless annotation does not make sense;
its container which treats it like EJB.

[Joe San]

Just to bounde back o this topic to get some good clarity, below is what I found from the EJB 3 in Action book,

■ A session bean class can subclass another session bean or any other POJO.
For example, a stateless session bean named BidManager can extend
another session bean PlaceBidBean in the following way:
@Stateless
public BidManagerBean extends PlaceBidBean implements BidManager {
...
}
■ The business methods and lifecycle callback methods may be defined
either in the bean class or in a superclass. It�s worth mentioning here that
annotation inheritance is supported with several limitations with EJB 3 session
beans. For example, the bean type annotation @Stateless or @Stateful
specified in the PlaceBidBean superclass will be ignored when you
deploy the BidManagerBean. However, any annotations in the superclasses
used to define lifecycle callback methods (more about that later in this section)
and resource injections will be inherited by the bean class.

The second bulleted point says that when I fail to mark my subclass bean as @stateless and I deploy my subclass bean, then it is not considered as a bean at all but the life cycle annotations are inherited (the container callbacks). My question is when the class itself is not recognized as a bean then what is the use of inheriting the container callbacks?