File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Subclassing rules for Session beans Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Subclassing rules for Session beans" Watch "Subclassing rules for Session beans" New topic
Author

Subclassing rules for Session beans

Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9618
    
    2

For example, I have a Local interface as,



And the implementation class which is a stateless bean like,





Can anyone explain me on the Annotation inheritance?


SCJP 1.4, SCWCD 1.4 - Hints for you, Certified Scrum Master
Did a rm -R / to find out that I lost my entire Linux installation!
nitin pai
Ranch Hand

Joined: May 30, 2006
Posts: 185
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 Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9618
    
    2

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
Ranch Hand

Joined: May 30, 2006
Posts: 185
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 Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9618
    
    2

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
Ranch Hand

Joined: May 30, 2006
Posts: 185
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é
Sheriff

Joined: Nov 24, 2005
Posts: 14688
    
  16

I tried this on Glassfish :


The client :


It's funny that it worked


[My Blog]
All roads lead to JavaRanch
Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9618
    
    2

So Nitin, did the specs go wrong?
nitin pai
Ranch Hand

Joined: May 30, 2006
Posts: 185
Originally posted by Jothi Shankar Kumar Sankararaj:
So Nitin, did the specs go wrong?


Do you even know what specs means?
Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9618
    
    2

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 Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9618
    
    2

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


The client :


It's funny that it worked


Any takers on this?
Sergio Tridente
Ranch Hand

Joined: Mar 22, 2007
Posts: 329

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?



In the client:


Please, post results. :-)


SCJP 1.4 (88%) - SCJP 5.0 Upgrade (93%) - SCWCD 1.4 (97%) - SCBCD 5.0 (98%)
Christophe Verré
Sheriff

Joined: Nov 24, 2005
Posts: 14688
    
  16

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é
Sheriff

Joined: Nov 24, 2005
Posts: 14688
    
  16


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

Joined: Mar 22, 2007
Posts: 329

Originally posted by Christophe Verre:

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


Sorry. My mistake. I meant something like:
Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9618
    
    2

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
Marshal

Joined: Jul 20, 2005
Posts: 10288
    
168

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.


[My Blog] [JavaRanch Journal]
Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9618
    
    2

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
Ranch Hand

Joined: Feb 12, 2001
Posts: 93
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 Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9618
    
    2

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
Marshal

Joined: Jul 20, 2005
Posts: 10288
    
168

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
Ranch Hand

Joined: Feb 12, 2001
Posts: 93
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
Ranch Hand

Joined: Jul 06, 2008
Posts: 85
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.


SCDJWS 5.0, SCBCD 5.0, SCWCD 5.0, SCJP 5.0
sanjeev mehra
Ranch Hand

Joined: Feb 12, 2001
Posts: 93
thanks for reply.
for compiler @Stateless annotation does not make sense;
its container which treats it like EJB.
Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9618
    
    2

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?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Subclassing rules for Session beans